One of my biggest concerns is still that users will tend to misapply the feature. Version tags only provide value if they mark the actual version range where an answer is valid. But if there is a field called "version", I suspect a not insignificant number of people will add the version they used or the version the asker used there, no matter whether the answer is actually specific to those versions.

The correct version range can actually be rather hard to know even for an experienced developer. In most cases the right choice is to leave out the version range entirely if you're not sure. The biggest benefit here comes from the more obvious version cliffs, cases where languages or framework has some bigger changes.

The guidance on this feature might need to emphasize that leaving this empty is an entirely valid choice, and that you should only enter versions if you know your answer doesn't work in some versions.

For me the benefits of this feature are almost entirely in handling the more popular, canonical questions. Those attract the biggest set of answers spanning many years, and are the most likely to gather highly upvoted but outdated answers. I think you can safely ignore the long tail here, if I'm looking for a more obscure topic I'm happy about anything I find, I don't need to filter the few results even further.

It might also be worth to select tags by the amount of trouble versioning has caused there. My view here is certainly biased by my experiences, but there are some areas that just inherently have more trouble with versions compared to more stable technologies. For example, in JavaScript I almost always scroll through a large part of the answers to see if anyone has posted an answer that isn't limited by being written for a browser that would be old enough to drink today. Being able to filter for modern JavaScript would be helpful here.

I would not try to automatically get available versions from somewhere. I would be inclined to only start with major versions anyway, and I'd feel more comfortable if the list of versions was curated by people familiar with that area.

It might be helpful to capture some of the ideas of how answer labels could be used on sites that don't deal specifically with software versions. Use this wiki answer to capture ideas for different sites in one place. Maybe there will be sticking points that several sites have in common that can be fixed with a small design tweak.

Closely modeled after the tag synonyms workflow...

Kill me now!

But seriously, as proposed, this is going to be one more thing that needs curating. Inexperienced users will create new "labels" just as they do tags, and it will be a mess. I do think this could be a useful feature, but I'd prefer to see it tied to existing tags.

On Stack Overflow, we have, for example, python-2.7 or php-8.0 tags. They already have descriptions and wiki articles associated with them. Let's find some way to reuse that information and avoid building out new infrastructure to manage this stuff.

I wouldn't say this is necessarily a bad idea, but I would be very cautious, at least.

• The answers of 99% of questions don't need versioning

  This is for Stack Overflow, at least, and based on the answers I've seen.

  On some sites it may be the case that essentially every question should have some sort of "versioned" answers (e.g. which countries it applies to), so consider this as being specific to Stack Overflow and other technical or programming sites where this would be used for versioning.

  For many questions, it might be the case that there are some very different solutions for very old versions, but most questions and answers focus on the newer versions (which means versioning probably won't be useful there, especially if the end-of-support date for old version has long past).

  Where a question is particularly old, many would see some given solution as simply outdated, rather than just "applies to an older version" (which is technically the same thing, but outdated answers should be removed or put aside, whereas something which applies to an older version may still be relevant).

  You could argue that versioning can be extremely helpful in that <1% of cases. But do we want to add something that will be useless in 99% of cases to deal with that 1%? Maybe it's better to just trot along with the current somewhat-hacky solution of writing version numbers in answers themselves. Maybe there's another, better solution out there.

• Users don't need versioning in 99% of cases

  Similar, but slightly different to the above. Even in cases where there are different solutions for different versions, it's often the case that the other solutions are for quite old versions and most users are just going to go for the solution for the most recent version (or at least the current most popular version or range of versions).

• Versioning probably won't be applied to all answers to a question

  Versioning would work best if it's applied to all answers to a question.

  If I search for some version and I only get back 1 answer, where many answers actually apply to that version, this may be less helpful than simply showing all answers.

  Getting versioning on all answers on a specific question would be quite difficult, to say the least.

  Maybe this is just a temporary problem, but there will always be new questions and answers for which this temporary problem exists. I don't think it would ever be viable to require answers to specify the version range (we could perhaps require one version, i.e. their version, but that wouldn't be all that informative for anyone using a different version).

• Which versions does it even apply to?

  This can be a hard question to answer, and it can be harder still to moderate or validate this to any significant degree. In some cases it would be quite trivial to spot an incorrect version range, but even experts may have a hard time knowing exactly which versions something applies to off the top of their head, without doing at least some research (if not a lot of research).

• Where's the line between this and (question) tags?

  We have one question that asks how to sort in C++ and one about how to sort in Java. Similarly, you could have a question about how to sort in C++11 and one about how to sort in C++20. The former is a difference in tags, the latter is a difference in versions.

  One might argue that the difference between different languages like C++ and Java is much greater than the difference between different versions of the same language. Also, versions can have a range, whereas this does not apply across different languages. Further still, there's an overlap between what works for different versions that doesn't apply across languages. I'd probably agree with all of that.

  However, the line between a question tag and "an answer tag" still seems blurry. Can we come up with some clear and objective differentiator between the two?

  Just off the top of my head, this could become a problem if we start thinking about:

  • How to handle different libraries within the same language. For example, maybe there's some elegant way to sort in C++ using Boost, yet it doesn't really make much sense to ask "how to sort in C++ using Boost", so maybe we want to be able to add a Boost tag to an answer. It seems like this may be possible to achieve with this functionality, but the point is that we would have both a Boost tag for questions that are specific to Boost, and a Boost tag for answers that are specific to Boost. This may add some redundancy and confusion.
  • One language that's built on top of another (where many of the same solutions may apply, e.g. Groovy/Java)
  • Applying this to other sites (where it may be very useful to use this feature to differentiate categories, e.g. countries, rather than sequential versioning).

• What about answers containing multiple solutions?

  This problem should speak for itself: different solutions may work for different versions, therefore it wouldn't be possible to version an answer containing multiple solutions.

  One might argue that such an answer doesn't really fit with how Stack Overflow is supposed to work, but such answers do still exist, and we may not ever really stop them from existing (and, as mentioned above, versioning would work best if it's applied to all answers to a question).

• Pushing users to use bounties (or, rather, to plead ignorance or go elsewhere)

  Perhaps this is more related to a personal problem I have with our "official" solution for getting a different answer to an existing question, which is the bounty system. The "right" solution is to pay your own reputation to add a bounty to that question (which isn't even an option for new users), whereas the "free" solution is to simply ask another question, pretending that you haven't seen the original and hoping to outrun duplicate closure (which is not something I endorse, but it is something the bounty system encourages), or to simply ask somewhere else (which makes us lose out on valuable content). I don't want to get into other solutions for this here, though (but if we agree it's a problem, we should probably try to fix this first).

  Previously one might've been able to ask "how do I do this in C++11", without having your question closed as a duplicate of "how do I do this in C++". Some people may close it as a duplicate anyway, and it probably should be closed as a duplicate (with a relevant answer added to the latter), but closure is far from guaranteed, especially not immediate closure (and subsequent deletion). If it's closed later, it can still stick around (and add value) and it should be much easier to transfer solutions from the duplicate to the original question. The questions may even be "merged", with a few small edits to the answers of the duplicate.

  With this functionality one might say all questions that only differ in version are necessarily duplicates and this makes a much stronger case for closure, pushing users more towards using bounties, pleading ignorance and/or going elsewhere.

I see 2 major problems with this:

At first, we would like to open this feature up to moderators and gold tag users exclusively.

1. A lot of tags only have one single gold badge holder and curation is frequently done by silver/bronze badge holders who are years away from getting a gold badge.

How might we handle answers that have been inappropriately labeled?

2. Versioning is a lot more complicated than it might seem. If the official documentation doesn't say the date when a functionality was introduced:

   2.1. Answers will mostly be tagged with the current versions - which are probably only partial.

   2.2. In many cases you'd have to search the release notes of a library/software to determine the lower bond of the version/compatibility. Because if you don't, you're introducing misinformation.

How much effort do you foresee label management to be?

Plenty. But it is not something that has to be done overnight. It is a marathon, not a sprint. But each labeled answer will immediately bring benefits to visitors that land on the particular question.

Also if answerers start labeling at least some of their highest voted answers the whole process might go faster.

How might we handle answers that have been inappropriately labeled?

Flagging (open to all or some minimal reputation to prevent initial flag flood) and a review queue available to the users with some experience in the tag. I would probably include all tag badge holders.

Flagging should also show a notification to the OP. Authors, if still around, will commonly know to which version an answer applies and can label answers accordingly, saving reviewers from some work.

If the review queue gets flooded, adding some delay between flagging and putting answers in the queue might give an author a chance to update the label. Delay can also be automatically calculated depending on how full the review queue is.

Which tags and qualifying criteria do you think we should consider?

You can add some more prominent tags automatically, for the rest you can post a Meta question and ask for tag nominations (for initial rollout). For instance, I am interested in adding versions in the Delphi tag where I have a gold badge, but it is definitely not among the most popular tags.

Thoughts and strategies for handling the initial population and rollout in the most responsible manner

Awarding reputation is usually the greatest problem for smooth implementation of "new features". Reputation attracts reputation hunters and the whole thing may blow before you realize there is a problem. Without the reputation incentive, things are more manageable and some tweaking can be done along the way.

What considerations are we missing?

• There should be an "All versions" label that would explicitly state an answer is valid for all so we can differentiate between answers valid for all versions and those that were just not labeled yet.

• Next to each version label there should be an option to include an open range marker (lower or upper bound) to indicate that version applies to all older or newer versions. For instance: Android API 19 +

  This may still involve some future label updates, because in the future answers might no longer apply to some new versions, but this will still be less work than updating all answers manually after some new version comes out.

• Sorting answers by version, but that is something that can be added later on.

When we ship this initially, we will not be building in any search functions that would allow you to search for answers with a specific label through the site search — but this is an expansion we may consider at some point in the future.

Please add this to your roadmap. Search is bad in a lot of ways; everyone knows this (it isn't really a secret that it's much better to go to google and add the site:stackoverflow.com filter or whatever specific network site you are searching on).

By introducing a new filtering option for answers, but not adding in support for filtering Search by that new option, you are reducing the usability/efficacy of Search even further.

For example, if we allow version labels, we will start to see questions for Python and Bootstrap tagged as python python-3.x arrays or twitter-bootstrap bootstrap-4 multiple-columns... I expect users will want to apply version labels to their answers, leading to noise/repeated meta content (e.g. 'OK, all the answers here will be 3.x-and-up or 4-and-up, at least until newer versions come out').

Do we then remove the version-specific tags from the question then? If we do, that would allow newer version labels to be applied to newer answers where appropriate... but if we can't filter Search based on those labels, then we've actually made the questions less findable by removing the version-specific tags from the question... they'll just be tagged python and twitter-bootstrap now.

For questions about the R programming language (the 14th most popular tag on SO), answers can often be categorized according to the collection of libraries used to accomplish the end goal.

A prototypical example might be the question How to Join (Merge) Data Frames (Inner, Outer, Left, Right):

The first answer could be categorized as base, or using only the standard R funcitonality.
The third answer could be categorized as data.table.
The fourth answer could be categorized as tidyverse.

Users often have strong feelings about the "appropriate" set of libraries that "should" be used in different circumstances. It seems like this feature could be easily extended to this situation, and it might be a shame to limit it strictly to numeric versions.

Surely this situation arises in other languages.

I'm missing some good example questions with version labels in order to better judge how useful this feature would be and how much effort it would be. Therefore I looked up some of the most visited questions on Stack Overflow and commented on how much work vs. benefit version labels would bring. I chose the most visited questions in order to maximize potential impact and I cannot realistically check many on my own.

1. How do I undo the most recent local commits in Git? (10m visits)

Deals with Git. Git has version. Has so far 98 answers created between 2009 and 2021, therefore answers could span quite a large range of Git versions. However, I cannot find version specific content. Maybe it's a (rather complex or very popular) feature of Git that was already present very early and hasn't changed since then.

Conclusion: Version labels not needed.

2. How do I delete a Git branch locally and remotely? (9.2m visits)

Deals with Git. Git has version. Has so far 41 answers created between 2010 and 2021. It seems to come down to "git branch -d/git push -d" now. Top voted answer includes solutions for Git 1.5-17, >1.7 and >2.8. How many version labels would that answer get then? I guess Git>1.5 only, because it's the shortest possible label including all the solutions in that answer. Most other answers do not contain version information. Not all refer to the currently preferred solution.

Conclusion: Version labels would be helpful.

Although: Is somebody really using older Git versions anymore or is this just of historical interest?

3. How can I remove a specific item from an array? (8.9m visits)

Deals with JavaScript, which has versions. Has so far 112 answers created between 2011 and 2021. Top voted answer does not contain version information. Second most voted answer specifies content for ES 5, 6 and 7. Most answers are variations of slice or filter which seem to be available in ES5-7 but with slight variations.. Only a few specify JavaScript versions.

Conclusion: Version labels might be helpful.

4. How do I find all files containing specific text on Linux? (8.2m visits)

Something between SuperUser and programming problem. Linux/bash/grep may have versions but not sure if they are relevant here. There are 53 answers created between 2013 and 2021. It seems to boil down to find or grep. No version information is given anywhere, maybe grep/find syntax hasn't changed.

Conclusion: Version labels probably not needed.

5. How to create an HTML button that acts like a link (7.8m visits)

Deals with HTML (CSS, JavaScript) which has versions. Gathered 37 answers between 2010 and 2021. Third most voted answer uses an external framework (bootstrap) and mentions visual differences in appearance depending on the used version (does this warrant a version label?). The fourth top voted answer mentions that the solution is not compatible with HTML5. The fifth top voted answer mentions that the solution is for HTML5. I wonder what the two top most voted answers are valid for.

Conclusion: Version labels would be helpful.

6. How do I revert a Git repository to a previous commit? (7.6m visits)

Deals with Git. Accrued 41 answers between 2010 and 2020. No answer seem to mention Git versions. Probably there is no dependence on Git versions in the required methodology. People seem to add answers because the question is not clear enough (what does it mean to revert Git repository) and leave room for interpretation.

Conclusion: Version labels not needed.

7. How do I redirect to another webpage? (6.9m visits)

Deals with JavaScript and jQuery. Amassed 58 answers between 2009 and 2018. Third top voted answer mentions browser versions. One other answer mentions a JavaScript version, none mentions jQuery versions. The solutions are pretty much the same (window.location) and are probably not dependent on any version.

Conclusion: Version labels not needed.

8. How to check whether a string contains a substring in JavaScript? (6.8m visits)

Deals with JavaScript. Accumulated a refreshing three answers in 2009, 2014 and 2017? Two mention versions and it seems like the solution is version dependent.

Conclusions: Version labels would be helpful.

9. How do I convert a String to an int in Java? (6.4m visits)

Deals with Java. Collected 47 answers created between 2011 and 2021. Two answers seem to have found solutions that only work with Java 8, the others do not mention versions. Not sure if versions are needed.

Conclusions: Version labels probably not very helpful.

10. How do I check out a remote Git branch? (6.1m visits)

Deals with Git (again). Gathered 38 answers between 2009 and 2021. The first two top voted answers mention versions, but it's not clear if they also offer solutions for other versions. Most other answers do not mention versions.

Conclusion: Version labels might be helpful.

Summary:

• There are lots of answers to label, which will be a lot of work. Check for yourself, if you could do that (if you are a gold badge holder) and if you actually wanted to do that.
• There may be duplicate answers. They should probably rather be cleaned up instead of further augmented by labels.
• Not all questions and answers will benefit from version labels but some might. Check for yourself, if you think it would actually be worth it.

I'd like to move a topic from the comments to an answer:

If a version range is specified, does this mean the answer does not work outside the range, or does it mean it is not known whether it works for other versions?

For a language like JavaScript or C++, where backwards compatibility is generally maintained and there are just "major versions" (e.g. ES6 or C++17), maintaining an accurate range is possible, but for languages and frameworks which are not formally specified but driven through their implementation, it might not actually be possible to tell with which version an answer works (due to the lack of release notes, or even legacy systems on which the old version could run). For those it would be useful to specify the versions with which the answer definitely works, leaving it to further readers to test it on their system. It would be useful to maintain this information in the version range, e.g. through a checkbox ("the answer does not work outside this version range").

Version ranges

It's not clear from this post how version ranges will work.

Can they be open-ended? E.g. "from C++20 onwards" (obviously subject to edit in 20 years' time when a future standard makes the answer less appropriate).

Will they be inclusive or exclusive? It seems we'll need both. E.g. "from Python 2.7 inclusive to Python 3.x exclusive".

How will the ordering relation between versions be managed, given that not all technologies use the same format, or even numeric versioning? The question mentions "chronological order" which might work for ISO standard languages such as C, but that seems a poor choice for Python, where 2.7 > 3.1 chronologically, but in terms of development line, 2.7 < 3.1.

I think there should be a way for moderators to "lock" certain tags to prevent labels from being created (I mean, regex for example might benefit from labels, but for flavors rather than versions. And we already have tags to handle that context... sort of). For example,

I think one huge top tag should probably not have version labels: the css tag.

CSS versioning is kind of a messy situation:

1. There used to be just "CSS1, CSS2, and CSS3" back in the day, but for years now CSS has been split into many separate modules: Grid Layout, Flexible Box Layout, Box Alignment, Color, you name it. Each of these modules is versioned independently of one another. So there isn't really a "CSS 3" anymore... it's about the module that covers the properties you're working with. Flexbox is at "Level 1", Grid is at "Level 2", and Colors is at "Level 4", for example.
2. You can't really work with CSS on its own... it's gotta be interpreted by some program... usually a web browser (but not always). The thing is, web browsers don't necessarily implement all of a CSS module at once; browser dev groups work property by property, feature by feature, sometimes taking years between adding initial basic support for some feature and fully supporting it per the CSS specification. Because of that, people write answers to CSS questions based on what the tagged browser(s) support (if any is tagged), not what all of CSS can do.
3. Browsers are also evergreen. They update constantly and often automatically. Most people usually do not tag a specific version of a browser (many such existing version-specific tag uses are actually unnecessary after a new version has been released... what matters is someone has an issue in "the latest version of <browser>" at any given time). We used to see this more back when IE was heavily in use, but now what extremely few instances there are of people using IE, it's guaranteed to be 11... as the last point mentioned, people write answers based on what IE11 supports, not what the CSS2.1 spec includes.

For these reasons, I think sticking with just css and using a browser tag or version-specific browser tag is sufficient.

How might we handle answers that have been inappropriately labeled?

Adding to the users that already proposed flagging and review to be the solution here, I think we should add a warning to the labels once they are flagged for being incorrect/incomplete. That way subject matter experts who organically land on the answer can edit instantly to correct any mistakes.

Please never let anyone else other than gold-badge holders and moderators add the labels! It will be a nightmare to clean it up after inexperienced users. Many of them already do not know the technologies they post answers in and letting them decide version it applies to is a very bad idea.

This means that tags that have no gold-badge holders will never use labels, but that's ok. You can always say at the start of the answer, which version it applies to.

That brings me to my other point. What added value does this bring other than letting readers know the version it applies to? The text of the answer can already say that information if it's important to know. If the question asks about a feature that was added in a specific version, we use tags for this. If the question doesn't specify the version, and the answers cover multiple versions, then do the labels help with SEO or with finding the right version faster than scrolling through all the answers in the thread to find the right one?

Open the feature to moderators and gold badge holders who can add labels invisibly (without bumping) for a few weeks before making it visible to everyone.

This is a great idea. I think it is sufficient for the first round of prepping existing content... a period of one month seems like plenty. I thought about keeping such edits from bumping permanently but I guess there's a good reason to want that notification in case someone goes off and edits 10,000 questions overnight again like they did a few years ago on Stack Overflow.

Creating a dashboard on the 10k tools page to identify high-priority questions that may need labels - base priority on things like recent views or recent upvotes.

Another great idea. Should probably be limited to the pool of tags that have versions to begin with... don't suggest a post might need version labels if its question's tags don't have any version labels yet. I think first-time labels will get created pretty efficiently by users organically as needed, and this will save on a lot of noise in the 10k tools, not to mention a lot of processing power/time on your part.

This image shows a lot of extra space in the columns, especially the Version label (if it's going to always be numerical, there's space for like 15 digits there!). I'd rather see the columns take up less width, and the "Edit" and "Delete" be brought up one level to be achievable in one click rather than require a second click, after clicking the ellipsis button.

Thoughts and strategies for handling the initial population and rollout in the most responsible manner?

Aside from the above, I think long term this feature should be gated behind silver tag badges. Having a tag score of 400 across 80 non-wiki answers is no mean feat. However, it's also quite a bit easier to achieve than a score of 1000 across 200 non-wiki answers, especially for tags which don't have that much activity (or that get answered by the same users who aren't interested in such user moderation tasks as 'applying/maintaining version labels').

Gating the feature behind silver badge tags gives way more security in terms of errant/abusive labeling compared to "a score of 5 in that tag", but also allows a much larger group of interested curators than just "mods (who aren't to be relied upon as SMEs) and gold badge holders".

At the very least, perhaps consider that gate for when users want to modify the version labels on non-Wiki answers that they didn't author (e.g. messing with someone else's answer), and letting users apply version labels to their own answer once they have a score of 5 in that tag (to match the tag synonym creation feature you were planning to mirror this off if).

Focused on Stack Overflow

1. Should version tags be part of the answers or part of the questions?

Making version tags part of the question (optional version range on every used tag in the question for example) would require less tagging overall and would better integrate with existing question tags, but would result in multiple questions for the same topic and existing questions with answers for multiple versions would need to be splitted.

Without versions on question tags (we already have Java and Python and other version tags) means that the answer list should really be filtered by version and it would be much work to tag all the answers. Over time question without version tags would become broader and broader (with an increasing number of versions), the number of answers would become more and more.

A compromise is also imaginable. For example major version tags on question tags and answer version tags only for minor versions within the version tag range given by the question version tag. Might reduce overall effort, but might also be even more confusing (spread of version information).

2. What should be the default assumption about the version if no tag is present?

The default assumption could be that the supported version of the code is simply unknown or that if no version tag is given, at least the present version is supported. Both is risky, because the answer was typically written at a certain time and will typically be valid only for a certain range. It mostly affects the filtering behavior though. Should answers without tag information always be shown even if a version range is specified or not?

3. Knowing the exact version range is really difficult and might even involve a time machine

Nobody knows how long code that runs for a present version will run also in the future. Only with hindsight one can determine the full version range really. We would need to basically leave the upper part of the range open unless we start with really old questions and answers because for them it might be easier to determine a proper version range.

Also the lower version border is difficult to estimate. When I write an answer, I presumably run the code on an actual system, but not on all previous versions, just to find out, exactly what is the minimal version for that solution. This might just be too much work.

4. Why not just mention the version in the answer body?

Could be done right now. Maybe already has been done. But in my experience, hasn't been done very often. I wonder why? Are people too lazy or maybe it's difficult to look into the future (see 3.). Advantage of an special tag system would be machine readability. So one really should have the ability to filter answers by versions then and also specify versions within the search system. Otherwise a big part of the advantage would probably be gone.

5. How to best prioritize version tagging?

I propose to start with:

• The most useful content (high score, high number of views).
• The most contested content (old questions with new answers).
• The topics/tags that are most prune to being outdated. Ask the community for that.

6. Should this be community driven?

Definitely. The community knows best, what it actually needs and wants out of that feature. Tags, qualifying criteria, disputes, initial rollout - for all these meta posts should be made and the solutions of the community be implemented (unless there are good reasons why not).

7. The big question: is it all worth it?

Let's not kid ourselves. This is a big work or people would already have added version information to the text of all existing answers.

The big question is, does it pay off?

I'm not sure. Usually when I encounter an answer, I can easily try out the code and see if it works for my system. Yes, answers are oudated and that doesn't necessarily mean it's because they were written for a past version. Often enough there are simply inferior (but would in principle still work). Versions wouldn't help there.

On the other hand, good answers often combine different solutions for different versions over time. Edits are being made and then in the text, there is a sentence telling me for which version range this part of the answer is valid. No version tags are needed for this.

Let's play it through. I arrive at a question I need the answer for. The first answer is outdated, the second answer is not. If there are version tags it depends on if the first answer would still work in practice. I would probably simply try both and wouldn't need version tags for that. But then I could also add version tags or add some text information saying that (already now and that may actually be enough).

Having version tags may result in people using them even where they are not so useful. In the end, time and energy could be wasted.

I'm really not sure, it will pay off.

In the context of Stack Overflow:

One of the things that would have to be considered along the way is when or if answering a question with a different version than the asker is using is allowed.

For instance, let's assume a question is asked about how to perform an action in the latest version of PHP. Would it be acceptable to post an answer for an older version of PHP?

Probably not, but what if a new version of PHP is released? An answer using the new version probably would be allowed, given that the question asks for the latest version.

However, now there's older answers for the latest version of PHP when the question was asked. Thus, begging the question: would it be allowable then to post the answer for all versions of PHP, since there's already an answer for an older version in the mix?

Perhaps, a more concrete and relevant question to ask is: should this feature be used to justify answering questions in any and all versions of the language, even if it's not the one being asked about?

My preliminary opinion is yes, but after the question has been answered in OPs language version. I don't know how exactly that would be enforced though.

Users will be able to add labels to answers as they would add tags to a question. Similar to tags, labels can be manually typed out or added via the suggestion popover. This feature will accommodate up to five labels as well as version ranges.

What about answers that include multiple solutions, targeted at multiple versions? Do you suggest to post multiple answers, one per solution, in the future, so that it can be tagged with the appropriate version (range)? And what about the thousands of existing answers that already do this? (Example A, B, C)

I think it would be much more useful to have version tags that can be included as content, using conventional [tag:something.vX/Y/Z] syntax, than to have tags added onto answers. I also would lift the restriction of 5 tags per answer.

This would be beneficial because it clearly allows multi-part answers to specify which part of the answer refers to which version, right in-line with the content. Don't have them "appear at the top of the answer" where they don't exactly fit. Also the answer form would be less cluttered (no extra tag section), and the potential for tag-abuse would be reduced (since new users simply wouldn't know about the feature - just like advanced formatting).

What about the (presumably very common) situation where an answer currently works in the latest version?

If it's tagged up to the current version, and it still works in the next one, then the tags are now wrong.

If it has an unbounded upper version, and it stops working in the next one, then the tags are now wrong.

It seems like this just adds another thing that can become outdated, creating more work in the future to solve the outdated version tag problem.

Yes, please! This would be extremely useful for mobile developers. Some questions have very different solutions depending on Android or iOS version. Marking solutions for old versions as outdated doesn't solves the problem, because developers may need those for supporting old devices. Currently tags like android-7.1-nougat are hard to find and useless IMHO.

Also version range on an answer can indicate, if it was tested on newer versions, without editing the answer itself.

I started as a strong proponent of version tagging for questions.

However, over the years, I have come to consider efforts to version tag questions, let alone version label answers, to be of very limited value compared to expending developer and volunteered effort in other areas.

Instead I think it is better to focus our efforts on encouraging users to include all relevant information in the body of their questions and answers, and also encouraging them to vote more on post usefulness.

I think that, wherever appropriate:

• Questions should mention the version(s) being used in their body;
• Answers should mention the version(s) they apply to.

If users find answers about old versions to be less useful to them than answers about new versions then, if they decide to vote, they are likely to downvote the former and upvote the latter.

To avoid a long list of answers, each covering a single version or a small range of versions, editors should be encouraged to improve answers so that they cover a greater range of versions. For example, I could envisage a question which was asked 10 years ago now having one answer for Python 3.x and another for Python 2.x, with code that is optimal for each. Initially the 2.x answer is likely to have more votes but as 2.x users became 3.x users, and upvoted/downvoted the answers they found to be useful (or not), the 3.x answer is likely to float to the top, while the 2.x answer sinks to the bottom.

Will it be possible to label only part of an answer?

It's very common when an answer is edited to add a solution for the current version, but the part with the old version stays unchanged.

As someone that writes answers to hard questions, this is a solution in a search of the problem. I've never seen an answer where the problem was the version, in most of cases the answer didn't work in the first place, because it relied on an esoteric configuration (which wasn't explained on the answer), didn't consider other inputs/outputs, it was generally brittle and the list goes own. I've yet seen myself typing "version X" on any of my questions (and seldomly on my answers) despite recently upgrading much of my stack (PostgreSQL, a bunch of R packages, Django 2 vs 3, etc.). Good software is often backwards compatible, and rarely breaks between upgrades. Heck, people needing to fix their code after the OpenSSL upgrade were basically asking for it using internal APIs which were not stable to begin with.

I see this feature seldomly used correctly only on the tiny number of posts that had an interim version that was snowflake special, and being basically an endless source of busywork adding these to any answer, even if the text itself specifies quite succinctly what are the requirements for it to work.

This seems like a fancy system to add sub-tags.

In theory, tags are supposed to be independent of each other. So the chicken means the same thing; it isn't supposed to mean one thing when paired with food and another if paired with driving.

This leads to driving-chicken and food-chicken being created. Here, the hyphenated tags are subtags.

In a slightly different sense, in c++, there are sub-tags c++11 c++14 c++17 c++20 c++2b (the convention is that future-standard versions are named with a letter, because standard dates have slipped in the past).

Those sub-tags are inappropriate to use on a post that isn't tagged with c++, which is probably also true of driving-chicken and driving.

Once you have this concept of sub-tags, versions become just another sub-tag. Adding sub-tags to an answer is similar to adding version tags to an answer.

Versions tend to be arranged in a line, while sub-tags are not always.

Another example of this is templates. Its use in html and in c++ are very different; the fact I have a gold badge in templates and can Mjölnir html questions if I wanted to is somewhat amusing to me.

We could go and mark every c++ question which also has templates with templates-c++, and similarly for html and templates with templates-html, because they are such fundamentally different things.

...

Backing up from this, right now your system is inclusive. You are claiming you want answers from specific versions or a specific range. In practice, people will want to include versions or sometimes exclude versions.

There is a slight difference between "I require version 11+" and "I don't want version 10 or before" questions. There is also a slight difference between answers stating "this works in version 11 or better", "this works in version 11" and "this won't work in version 10 or before".

The "this works in version 11" is a simple statement that "I checked it in version 11". The "this works in version 11 or better" makes a prediction about the future, which honestly could become undermined. "this doesn't work in version 10 and before" means you know you have used a feature that doesn't work in version 10.

How you set up your system will implicitly bias towards making one of these statements, and away from the others. I don't know which you should bias towards, nor what people will naturally do. This would require real user experience research.

feature-request

Make this feature a per-site setting and opt-in

Some sites removed version tagging from the questions, Unix and Linux being one. Sites should be able to opt in this feature since it can be relevant that such feature isn't desired or required on those sites.

Thoughts and strategies for handling the initial population and rollout in the most responsible manner

2. (...) up to five labels as well as version ranges.

A strategy for versioning nomenclature should follow current practices for each language. For example in Python:

PEP 440 - Version specifiers

~= 0.9, >= 1.0, != 1.3.4.*, < 2.0

which would have the label looking like this:

Django>=3.0

In the example screenshot in the question instead of an open-ended range two version number limits have to be defined which is not concise.