It's nice to have ways to highlight when something comes into the library, especially newer features xref: #15920
If we can add a tag for versions, that'll let us highlight what in the gallery came in on a specific version -> specifically new features. Tagging by version number means we don't have to move a whole bunch of tags on every new version. Adding "and add tag: N.M" to the other documenting new features instructions isn't a big deal.
Proposed solution
We should use the same format as the versioning directives, version: 3.N
I think so - it's still showing a feature that came in recently. I think the only complication is if an example warrants multiple version tags, making it clear which feature goes to which tag - but that may be a good usecase for putting tags in places other than the bottom if it's an example with multiple parts.
IMHO the Tag should only be set if the feature is the central aspect of the example. It should be rare that we‘ll have duplicate labels then.
More generally, labels can have two functions:
Show the minimal requirement needed for the example.
Draw attentions to new features.
The first one is not reliable, because minor aspects of the example may still need newer versions.
This leaves us with the second, so that we can always resolve to the newest version.
Activity
rcomer commented on Nov 9, 2023
Sometimes an existing example is modified to show a new feature, e.g. #23208. Would you still add the tag in that case?
story645 commented on Nov 9, 2023
I think so - it's still showing a feature that came in recently. I think the only complication is if an example warrants multiple version tags, making it clear which feature goes to which tag - but that may be a good usecase for putting tags in places other than the bottom if it's an example with multiple parts.
timhoffm commented on Nov 9, 2023
IMHO the Tag should only be set if the feature is the central aspect of the example. It should be rare that we‘ll have duplicate labels then.
More generally, labels can have two functions:
The first one is not reliable, because minor aspects of the example may still need newer versions.
This leaves us with the second, so that we can always resolve to the newest version.
story645 commented on Nov 9, 2023
I'm fine w/ that criteria and it fits w/ the other "versioning guidelines" criteria.