-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
[Tag]: version: 3.N #27292
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Sometimes an existing example is modified to show a new feature, e.g. #23208. Would you still add the tag in that case? |
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:
The first one is not reliable, because minor aspects of the example may still need newer versions. |
I'm fine w/ that criteria and it fits w/ the other "versioning guidelines" criteria. |
Need
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
The text was updated successfully, but these errors were encountered: