Released version means, well, it's out so you should not be able to assign new things to it.

Obsolete version means support has been discontinued so you should not be able to fill bug concerning it.

Confirmed.

when reporting a bug you should not be able to assign a target version which has been marked as

• released

That makes sense, I guess.

• obsolete

This is already the case today, as far as I can tell. Please provide steps to reproduce if you notice differently.

you should not be able to assign a product version which is marked as obsolete.

Same as above. On my setup it is not possible to select obsolete versions in the Product Version field.

On my setup is possible to select released versions, but not obsolete ones

Damien, I'm not sure this change works 100% as intended. As an manager I sometimes retroactively assign issues to released releases, for better tracking what work has been done. This change breaks that workflow.

I think this should be allowed, or at least guarded by a threshold.

Good point, I did not think about this use case.

Looks like this is also an issue in other situations as well, see 0014045

EDIT: On second thoughts, I'm not sure whether the related bug is indeed the same case.

This change will be reverted in next release. A better solution will be designed and implemented later, probably using a threshold as suggested by rombert.

Follow up in 0014111.

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch

This change will be reverted in next release

For the record, I found out today (see 0010840:0068837) that the revert mentioned in 0011706:0031580 was actually only applied to the 1.2.x branch and not in master, resulting in a somewhat inconsistent state between what the bugtracker says, and what is effectively implemented in the current 2.26.1 release.