130

We’d like to introduce version labels (official name and verbiage pending) for answers, a new product feature idea as part of the larger Outdated Answers project. We hope that this feature will help users more easily identify relevant answers that resolve their problems, as well as highlight opportunities to provide newer, up-to-date responses to existing questions. Version labels are currently in the early phase. We’ve illustrated some initial ideas on how this might work on Stack Overflow. We’re interested in your feedback and hope to incorporate it into further iterations.

Note: We know that several sites have already shown interest in a feature like this and we believe that it has potential for use on many of the sites across the network (such as Role-Playing Games, Code Golf, and Puzzling), but this initial investigation, we will be focused on Stack Overflow and technology versioning.

1. Version management

Version labels are directly related to existing tags. We are considering using package managers to import major and first-level minor releases from languages/tags with X amount of questions. We're still defining what that minimum-bound may be. Tags that fall under the minimum requirement will have manually generated labels using the label management workflow.

Closely modeled after the tag synonyms workflow, the label management workflow will be gated behind a reputation requirement. At first, we would like to open this feature up to moderators and gold tag users exclusively.

  • Users will be able to create new labels from the Versions pages OR propose new labels when writing an answer post.

a table view of pending version labels related to python

modal showing option to create a new version label

  • From the Timeline view (for versions on the tag), users may see all available labels for a particular tag in chronological order. Version order will be set based on built-in sorting rules and can be modified by users here as well.

a table view of version related to python in chronological order

2. Adding version labels

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.

an input field for version labels appears below the answer editor

3. Answer filtering and labeled answers

We'll be adding a new filter option to the top of the answer section of each question page. These filters will be generated by the labels being used on the answers themselves.

Answer version labels are ultimately optional. If they have been applied, they'll appear at the top of the answer. 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.

In terms of moderation, label editing will function similarly to tag editing in such a way that sufficient reputation levels will allow users to edit the labels alone without editing the post body.

version labels appear above each submitted answer

4. Labeling millions of answers

One of the concerns that we have is that we're introducing this feature after 13 years of content has been created on Stack Overflow - figuring out which tags to prioritize and which answers need labels - and how to get those labels added accurately so that this feature is useful - is a big question.

We're considering having a beta period where we select a subset of tags as an opportunity to test out the feature before opening it up site-wide. We're really interested in ideas for how to identify these starting tags and prioritize these answers to be labeled.

Here are some considerations:

  • 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.
  • Choosing only the top 20(?) tags to start out based on some metric - e.g. recent questions asked, total questions asked.
  • 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.

Open questions for feedback

As mentioned earlier in this post, version labels are in the product-discovery phase. We are actively working on what the initial release would look like and will continue to make subsequent releases.

We know that this is going to be a massive effort and we’ll chip away at it over time, but we'd love to read your thoughts on how we could go about simplifying this process and get people involved in making these edits.

  • How much effort do you foresee label management to be?
  • How might we handle answers that have been inappropriately labeled?
  • Which tags and qualifying criteria do you think we should consider?
  • Thoughts and strategies for handling the initial population and rollout in the most responsible manner?
  • What considerations are we missing?

Our efforts may be focused on implementing this on Stack Overflow, but please feel free to share how you might see this feature being used on the Stack Exchange sites by specifying the site in your response.

58
  • 35
    I feel like this would be better off posted on Meta.SO at this stage. And maybe create a separate post here on Meta.SE to discuss the "feel free to share how you might see this feature being used on the Stack Exchange sites by specifying the site in your response" part. I.E., similar to how it was done in this post.
    – 41686d6564
    Oct 7 at 19:08
  • 18
    I just skimmed, but it seems like the awesome idea to be able to tag answers is completely useless for any site that is not software related because you're forcing it to be a version number instead of an arbitrary site-specific classification.
    – ColleenV
    Oct 7 at 19:14
  • 26
    @ColleenV There's not actually anything that requires the content of the label to be a number - that's kinda necessary because some companies version things with alphanumeric character sets. So, if you're thinking in context of ELL, I can definitely see a place where someone could toss a AmE label on an answer if they wanted to - though, what you're probably catching is the case - Labels are (currently) tied to a specific tag, so there would have to be at least an "English" tag that you could pull the AmE or InE or BrE Label from. But I think that could be solved.
    – Catija StaffMod
    Oct 7 at 19:18
  • 11
    @ColleenV RPG is mentioned and that's a very good fit, as well, since the systems are also versioned. Some don't even have numbers but admittedly most do.
    – VLAZ
    Oct 7 at 19:35
  • 10
    @pxeger I don't think there's anything about this project that precludes that and I welcome an answer outlining your thoughts in that arena. Initially we'll be focused on SO but we want to think about how flexible we need this system to be so that other sites can use that - whether it's Travel or Law using country Labels or Language sites using Labels as I've already outlined or Code Golf using Labels to sort answers by the language used to golf the answers - that's all stuff we're aware of. Once we get past the first iteration and start looking at the network, we'll see what we can do.
    – Catija StaffMod
    Oct 7 at 19:42
  • 10
    @ColleenV I understand what you're saying - I do! I think, to some degree, this feature was designed as an opportunity to help improve answers on SO... and it just happened to be that other sites wanted to have something similar, too. As a company we can't help but focus on SO - we know about and care about the other sites but SO is our focus and I don't see that changing in the near future. As such, many features will be built with SO in mind and when they have value to other sites, we'll try to keep those use cases in our sphere of awareness so that we can extend the feature to them.
    – Catija StaffMod
    Oct 7 at 19:45
  • 16
    @Catija I think the biggest thing that sticks out at me that makes it hard for me to imagine this as a general purpose thing is that y'all are referring to it as "version labels", not "answer labels", and talking about "version management" and importing packages. I'm a software developer, so I grok all that, but if you're looking for creative ideas from the non-programmer types, that's a barrier.
    – ColleenV
    Oct 7 at 19:45
  • 15
    @ColleenV The name is (as the question indicates) not final - I'd be OK with (and happy with) just calling them Labels generally or Answer Labels to make it clear they're for answers only - distinct from tags. We can always add a modifier for the name on some sites and not others, potentially - so on SO they can be "Version Labels" but on Travel they could be "Country Labels" or something else... but ... "naming is hard" as they say. ;)
    – Catija StaffMod
    Oct 7 at 19:47
  • 4
    @ColleenV I fully agree. Answer labels is more appropriate and it is not in contradiction with software versioning. Release dates are also not necessary if versions can be custom sorted. This feature can be expanded to more use cases than simple software versioning. Oct 7 at 19:53
  • 5
    @Catija This comment is an example of why I'm concerned about the presentation of the new feature. Already people are trying to shut down ideas because "this feature is for addressing upvoted outdated answers" (and apparently nothing else).
    – ColleenV
    Oct 7 at 20:48
  • 4
    This will be very helpful on gamingSE, too. Once I found 11 questions that basically came down to the same issue, with 35 answers in total, none of which working in any somewhat recent Minecraft version. Oct 8 at 1:03
  • 17
    "Closely modeled after the tag synonyms workflow" - I do hope it will avoid at least some of all the pitfalls that tag synonyms fell into, such as a lack of visibility from outside, not user-friendly (which has been improved, at least), tag score requirements that leave many synonyms unable to be approved (at this very moment, I can still see a number of tag synonyms that are quite a few years old, including one that's more than 10 years old). Maybe versions are different enough for these problems to not be that significant there. Oct 8 at 2:57
  • 13
    "Closely modeled after the tag synonyms workflow" - yes, please, address the issues with that system first if you are considering going forward with this. In the community I used to be very active, several gold, silver, and bronze badge holders and top contributors could not moderate our tags because of the crippling requirements for making synonyms. Instead, we had to rely on goodwill of a moderator who took pity on the whole "tagging" feature. P.S. Other than that - this is great news! Oct 8 at 4:05
  • 4
    By the same token we might have to figure out how to break up omnibus answers that address 8 different solutions in different versions - for example, there's some great answers to questions about SQL that explain specific solutions in each flavor of SQL.
    – Catija StaffMod
    Oct 8 at 15:48
  • 4
    @Trilarion The labels are only as valuable as the content they're posted on. I think in that specific situation I'd Label all versions where it works and have the answer itself explain the details.
    – Catija StaffMod
    Oct 9 at 17:42

25 Answers 25

121

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.

19
  • 1
    "For me the benefits of this feature are almost entirely in handling the more popular, canonical questions" care to show an example of this?
    – Braiam
    Oct 7 at 19:47
  • 18
    @Braiam Pretty much every "How do I do XYZ in Javascript" question, the kind of thing you need to often ask if you're not deeply familiar with the ecosystem. This is an example where the top answer covers all versions, but that is not always the case. Oct 7 at 19:53
  • 2
    If I'm reading correctly, the old solution still works in the "new" version. Is that correct? And if so, why not using ordering, the newest version first, etc.
    – Braiam
    Oct 7 at 19:57
  • 8
    @Braiam In most cases the modern solutions are much cleaner and more ergonomic. And because you use Transpilers today the backwards compatibility is much easier to handle now. The old solutions work, but I would almost always prefer to use the new solutions. Oct 7 at 20:03
  • 9
    +1 for "emphasize that leaving this empty is an entirely valid choice" but I also like the idea in Resistance Is Futile's answer about having an "All versions" option.
    – 41686d6564
    Oct 7 at 20:30
  • 3
    Some anecdata: I used JavaScript a lot 20 years ago, but I rarely wrote JavaScript for over a decade (but I've been using it a bit in recent months). When looking at JS answers these days I always browse the Active tab and I only bother looking at older answers (that might have scores 10× or even 100× higher than the recent answers) if I have no other option.
    – PM 2Ring
    Oct 7 at 21:16
  • 27
    a not insignificant number of people will add the version they used I actually think there is value in that, it provides the information that it is 'guaranteed' to work in version X. Maybe there could be a checkbox to distinguish "works in version X and I don't know about other versions" from "I know that this works only in version X / in version X and up / up until version X / in versions X to Y".
    – Marijn
    Oct 7 at 21:21
  • 5
    Yes, but the old solution still solves the problem, hence not obsolete. For me, and I believed that it was generally accepted, an obsolete solution simply doesn't work with newer technologies. I really like my definition.
    – Braiam
    Oct 7 at 22:02
  • 5
    I think maybe the version tag might be best added years in the future, when somebody tries to use the answer and it doesn't work. Think about all those "I tried this in version X.Y and it did not work" sort of comments. It's not quite that simple, I think you would need some kind of vetting on that, though. If it didn't work on Alice's computer at v1.0, but it did work on Bob's (sadly very common), then that "doesn't work in version X" statement was just false.
    – jrh
    Oct 8 at 12:41
  • I think the solution here is to gate the feature behind sufficient rep or tag score. The issue of gold tag abuse is minimal, for example. If gold tag badge holders and moderators are the only ones who can add them, that reduces the incidence of misuse. Lisa did ask for suggestions on how to handle it, so answers wouldn't be remiss to add a few suggestions there, such as "users with a bronze or silver tag badge and up can add version labels" or something.
    – TylerH
    Oct 8 at 14:49
  • 1
    "no matter whether the answer is actually specific to those versions". Example: Many new questions on the python tag are unnecessarily tagged with python-3.x and many are not. Inconsistencies! Oct 9 at 5:50
  • 1
    @braiam a 40 year old car still might work on roads, and with modern infrastructure, and modern petrol. But that doesn’t mean it’s not obsolete. A 10 year old Nokia still sends texts and makes calls, but it’s still obsolete. I think answers are the same: obsolete answers might work with modern versions, but perhaps they’re inefficient, slow, hard to read, hard to maintain / extend.
    – Tim
    Oct 12 at 15:59
  • 1
    @Tim the physical world is very different to the digital one, so analogies don't apply. Also, if that were the case, then why people that know crafts prefer old stuff over newer one? Well, because older stuff was built to last. Planned obsolescence and all the jaz. BTW, how do you establish that a programming language is obsolete? C is still around and kicking.
    – Braiam
    Oct 12 at 19:07
  • 2
    @Braiam and why do people that know crafts prefer old stuff over new? The same reason my grandmother used a paper diary, not an internet calendar. Why? It’s what she’s used to, there’s cost involved in switching, she doesn’t need the features of an internet calendar. Same applies to language users. Why are people still using PHP 5.4 when 8 now exists?
    – Tim
    Oct 12 at 19:11
  • 2
    @Braiam let me clarify. The definition of obsolete I’m using is “out of date, not current”. I see no reason why that definition doesn’t apply to software, hardware, programming languages, development models, medical drugs, elevator design, fire fighting techniques. Anything can become obsolete.
    – Tim
    Oct 12 at 21:26
48

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.

Site How labels might be used Possible Concerns Example labels
English Language Learners the "flavor" of English The timeline view/release date doesn't make much sense. It's hard to pick a "root" tag that isn't the meta tag "English" that would, much like grammar, get applied to way too many questions. AmE BrE
Law the jurisdiction The timeline view/release date doesn't make much sense. england-and-wales united-states
RPG rpg.meta discussion
the edition or version of a game's core rules (the main tag would be the game, like dungeons-and-dragons),
The way different games express their versions varies widely. Majority of questions concern one particular edition of a game. 5th-edition 3.5-edition
SFF different versions of the same story within a franchise (e.g., different media, continuities / canon levels, remakes, multiple timelines or universes, etc.) There are various ways of having "versions" books movie / star-wars-canon star-wars-legends
Code Golf the programming language that the answer is written in (since we typically don't want language tags) or the byte count of the answer The timeline view/release date doesn't make any sense and languages have sub-versions of their own python javascript
Chinese Chinese topolects In Chinese.SE it is rare to have questions that broadly ask about some term or translation with multiple answers for each topolect. Questions are usually well aimed to a topolect to begin with, and tagged accordingly Mandarin Cantonese Taiwanese Wu
Science & math sites specify the theorems, conjectures or techniques used It's of limited value for now, although being able to specifically search the answer tags will make it much more useful special-relativity general-relativity Euler's-theorem Bernoulli's-inequality
Workplace, Interpersonal Skills, Travel the countries the advice given applies to These sites tend to focus heavily on the specific details of a question, rather than giving more general advice, therefore the users on these sites may object to this and being able to specify a country may not be useful as it stands. The timeline view/release date doesn't make much sense. united-states united-kingdom
Christianity the denomination the answer given applies to Christianity.SE expressly forbids generic Christianity questions because they can't be reasonably be compared for the purpose of voting; we allow "overview" questions, but they expect an expertise nearly no one has; this would allow more people to participate on the site and make it easier for new users to ask questions without being goaded into asking about a denomination catholicism orthodoxy protestantism
Expatriates which laws were in place and apply in the given situation, and which laws apply now Immigration laws can be very fluid, and even citizenship laws (or their interpretation) get updates. It's very typical that the rules at the time frame that the scenario relates to are relevant, irregardless of what the current rules are, and occasionally vice-versa. pre-brexit brexit india-citizenship-act-1955 india-citizenship-act-2019
25
  • 3
    I put a few ideas in to get the list started. I probably didn't capture the ideas for sites other than ELL very well. I hope someone will come along an fix it :)
    – ColleenV
    Oct 7 at 20:39
  • 10
    This is nonsense because it overlaps with the use of tags as they already exist. E.g American English and British English already exist. The same for Code Golf where the language is explicitly named in every post. Also for law which has country specific tags like united-states.
    – bad_coder
    Oct 7 at 21:36
  • 8
    The concern hard to pick a "root" tag is also applicable to technical sites that are centered around one program/language/type of hardware. An example that I know well is TeX.SE, which is (mainly) about the programming language LaTeX. Tags there are mostly used for libraries/packages, but the core language doesn't get a tag, while version labels for the core language would be useful. Sites with a similar issue may be (but I don't really know any of them, so maybe not) elementary OS, Emacs, Raspberry Pi, Tor, Vim.
    – Marijn
    Oct 7 at 21:42
  • 18
    @bad_coder On code golf, every answer has a language, but questions almost always are open to all languages and do not require or even assume a particular one (and doing so is even strongly discouraged in our question writing tips). Tags as they currently are do not work for this, as they are for questions only. And on law, if you browse a couple of questions you'll quickly notice region-specific answers to more broad questions. Oct 7 at 21:55
  • 1
    Do these sites struggle without this? Have they explored the existing tools? What have been their experiences?
    – Braiam
    Oct 7 at 22:00
  • 7
    @bad_coder The point is that this is like tagging for answers, something we don't have. Tags provide the advantage that they're easily searchable, whereas if you're looking for, e.g., England and Wales specific answers on Law you'd need to search various things since the wording could vary, and you'd get lots of false positives from people mentioning those countries in unrelated answers. Oct 7 at 22:07
  • 3
    @bad_coder Also an explicit answer tag prompt in the interface may promote the use of such tagging for new users, even if the tags themselves have no actual advantage over tags/plain text mentions in the body of an answer.
    – Marijn
    Oct 7 at 22:15
  • 16
    @bad_coder a lot of questions on ELL don't specify a type of English so if there were cases where I was unsure whether my native AmE answer was universal, I'd often specifically state "in American English..." having a Label for that would be great. I could use the label to indicate the answer is specific to American English and if it was also true in British or Australian English, people could add those labels to the answer, too. But if it's different in Indian English, someone could post that answer and someone looking for an InE answer could find it easily.
    – Catija StaffMod
    Oct 8 at 2:32
  • 4
    RPG.SE tends to shut down questions that aren't specific about a version; only a small fraction of questions are intentionally [system-agnostic]. In those cases, yeah, a Q&A about drunk players for example have some answers with suggestions that depend on game mechanics from a specific game system like [fate] vs. [dnd-5e] or any version of D&D. Or there can be lore questions that span D&D history, where some lore facts simply differ between editions. So there could be some uses that aren't already covered by question tags, but not as common as on most sites. Oct 8 at 6:29
  • 1
    @RedwolfPrograms "Tags provide the advantage that they're easily searchable" [citation-needed] Tags are generally horrible to find something that you don't know the name of. That's why search engines are so good, they don't care about the tag, but the greater context.
    – Braiam
    Oct 8 at 10:58
  • 1
    @Braiam Maybe in some situations you don't know the name of something and you're searching for it on SE, but usually you'd just google the name of it. Or, just search normally, since tags don't replace (only improve) searching. If I'm looking for pre-ES6 solutions to a problem, I'd much rather be able to just click a thing to filter those, instead of having to do an inquestion thing and look through them all manually to find one that's not a false positive (and try a bunch of variations, since "pre-ES6" could be worded a thousand and seven ways) Oct 8 at 13:30
  • 7
    @Braiam The value is that it makes the answers easier to sort through and (if/when we make Labels searchable) search for. If you have a question with 6 answers and you only want the answers that you know relate to BrE, you can filter out the answers that are AmE specific. It doesn't necessarily prevent someone from adding the info to the post but - in some cases, people think their version of English is the only version of English, so having an indicator of "which version are you talking about?" could cause people to add information they might not otherwise.
    – Catija StaffMod
    Oct 8 at 14:57
  • 3
    I'm not sure if I got the gist of it properly, but some feature like this would have been great for Christianity.SE, if the answers had their perspectives tagged they could stand on their own under generic questions and wouldn't need to be considered to battling each other. Would there still be a "Best V2 answer" and "Best V3 answer", so "Best Catholic answer" could sit next to "Best Baptist Answer" without having to fight for who is right Oct 8 at 21:42
  • 1
    @PeterTurner I think it would be possible to filter by label and then sort by the standard sorts.
    – Catija StaffMod
    Oct 9 at 1:45
  • 3
    Sometimes the "version" used is not important at all.
    – PCM
    Oct 9 at 3:42
42

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, or 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.

10
  • 10
    At the outset we wouldn't let new users create labels and we'd be thoughtful when expanding the group of users who have the privilege in the end.
    – Catija StaffMod
    Oct 7 at 22:27
  • 5
    I did see that, and it's a good idea. But there are also rep minimums needed to create new tags, and we still get this...
    – miken32
    Oct 7 at 22:44
  • 19
    If I have my way, we'll be stepping away from rep-based privileges over time, likely starting with new privileges we create for new features. So I appreciate and will keep your concerns in mind but I'm hoping to avoid them entirely.
    – Catija StaffMod
    Oct 7 at 22:54
  • 2
    I look forward to reading more about that in the future!
    – miken32
    Oct 7 at 22:56
  • 7
    That sentence also tripped me. The tag synonym workflow sucks, at least for us regular users. The only tag synonyms I have seen created were created by a mod. Especially the little, useless tags would be good to turn into a synonym for another tag, and those are exactly the tags where nobody can vote on. Oct 7 at 23:18
  • 2
    Eh, its not that bad. You've never seen the old tag synonyms workflow
    – Journeyman Geek Mod
    Oct 8 at 0:22
  • 7
    I made a bunch of tag synonym requests like 5 years ago. Still haven’t been approved. And that’s on SO, I can’t imagine what it would be like on the smaller sites.
    – miken32
    Oct 8 at 12:06
  • 1
    @miken32 smaller sites a have far more moderators per user, and see much less traffic. Like review queues, I suspect there will be hardly any work, and non-moderators will probably fight over the one or two things in the workflow if a badge is attached to it.
    – Pureferret
    Oct 11 at 11:12
  • 1
    +1. Just use tags
    – cutrightjm
    Oct 14 at 2:27
  • I couldn't agree more ... what are tags in the first place? It's just metadata, which is what the "Answer Labels" or what ever you want to call them are going to be ... more metadata. If people are not paying attention to the tags, they aren't going to be paying attention to the labels. As cutrightjm states, "Just use tags." On point. Oct 14 at 11:16
24

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?

  1. 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.

5
  • Hopefully someone who knows a label is inaccurate would be able to change/remove it. If not, they could flag for a moderator to remove it and explain that, or post on Meta.
    – TylerH
    Oct 8 at 14:53
  • 2
    @TylerH there's no guarantee any of the mods have the necessary SME. Even for me in the smaller tags where I know my way around, if someone asked me to do versioning it would be a lot of work just to confirm one single answer.
    – bad_coder
    Oct 8 at 15:55
  • Yes, my point wasn't so that mods could come in and correct it based on their own knowledge, but rather that mods can do something to highlight that it has been flagged as incorrect or step in to pause a rollback war on the labels or something.
    – TylerH
    Oct 8 at 16:06
  • I don't think (2) is that much of a problem: Simply add the version the answer was written with, then over time, if users come by with different versions they can comment & edit and the range increases. Oct 10 at 15:38
  • If bounties counted towards the tag score, (1) could easily be solved by gold badge holders from other tags ... (unfortunately they do not) Oct 10 at 16:11
22

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.

24
  • 7
    I hate to be that guy, but how did you determine "answers of 99% of questions don't need versioning"? I say 99% of answers need versioning - can you disprove that statement? Because if not, I suspect a logical fallacy creeped in to the statement. Oct 9 at 14:05
  • 1
    @OlegValter Someone that has 1447 answers and only 44 mention "version" with most of the ones I checked not being about "software version", seems a good approximation.
    – Braiam
    Oct 9 at 17:47
  • 2
    @Braiam I suppose you aren't in the camp who thought that simply searching for "thank" counts as argument? Although when I do a search not restricted to a single person (and wouldn't you agree that network-wide upgrades should not be decided based on one's experience but on tangible evidence), I see 1.6M just for searching "version" (which itself is a search heavily biased to exclude every answer that does not use the word - try that for ECMA releases) out of 32M total which already gives us ~5%. That number is only going to go up Oct 9 at 18:16
  • 4
    Of course, "version" would not mean "version" for all of them. But the opposite holds true - far from all you think lacks "version" in it is not version-specific. This all just makes me consider the "99% don't need versioning" a catchy phrase without any foundation behind it. Oct 9 at 18:18
  • 1
    @OlegValter As I said, the 99% is "based on the answers I've seen". Also, answers containing versioning doesn't mean they need versioning (maybe it was already outdated at the time of writing, or maybe it's outdated now). Personal experience is not a great form of evidence of how common something is, but you don't even need that much to challenge implications suggesting otherwise (like that we need a feature to add versions to answers). As far as I'm concerned, the burden of proof would be on Stack Overflow to show that the problem it's solving is prevalent enough to justify the feature. Oct 9 at 22:20
  • 1
    @BernhardBarker however, this is not what you highlighted :) This is what an unsuspecting reader sees: "The answers of 99% of questions don't need versioning" and unless they are curious enough to challenge that assumption, this will look like a definitive statement to them. Can we agree on amending that to the "99% of the questions I've seen so far" then? Secondly, the burden of providing proof is never just on one side - it is on both sides. Some of us do think it will help - I participate a lot in the TypeScript tag, for example, and see version tagging as a clear benefit over having [1/2] Oct 9 at 22:30
  • 2
    [2/2] nothing. Of course, just adding version tags will likely end up in another exercise for us to waste the time on but accompanied with search and filter options it is going to be a quality of life improvement for many of us. Just because you do not see it as impactful does not mean it should not be implemented. Oct 9 at 22:33
  • 1
    @OlegValter "the burden of providing proof is never just on one side - it is on both sides" - well, kind of. If I want to build a building somewhere, it would be quite reasonable for you to expect a solid justification for that while providing little to no evidence from your side. Once justification has been provided, then you might address some flaws in that or provide evidence to counter that. ... Oct 9 at 23:50
  • 2
    @OlegValter ""answers of 99% of questions don't need versioning"? I say 99% of answers need versioning" Probably depends on the definition of "need". Given that versioning of answers doesn't exist yet, it's probably not needed in 100% of cases. Given that potentially it could improve things a lot, it might be nedded in up to 100% of cases. Truth is somewhere between 0 and 100. :)
    – Trilarion
    Oct 10 at 9:06
  • 1
    @BernhardBarker and I would agree with you were it a public hearing for a building where the company has a monetary interest. This is the case of a quality of life improvement that has also been asked for more than once. Those in favor of the versioning have already spoken their mind, this is now on those who are against it to show that the feature would be actively harmful. Because if not, even if there is only 1% of users who would benefit from it (which is highly likely a much higher percentage than you think), we should go for it. Oct 10 at 10:26
  • 2
    @Trilarion grr, I wanted to take a break for today :) But since you mentioned that - this is one of my concerns regarding the upcoming feature too. I am definitely not saying that the change does not have any potential to backfire, just do not share some of the more extreme views that a given feature should prove that it is perfect to even be considered. On the note of quality - this is also why I am begging to not use gold badgers and/or reputation as metric for the feature even in its pilot stage which, in my humble opinion, is just going to make it inaccessible to those who really [1/N] Oct 10 at 20:13
  • 3
    [2/N] care about curation and, for example, have experience in categorizing content on sites, while at the same time favoring those who prefer to produce content with little to no consideration of how such prolific production affects the community at large. As for your point of balancing the trade-offs yes, I do agree with that too, and as I mentioned, I actually share a position of caution and see a lot of ways where it could go wrong. Unfortunately, I also see many positions here that try to shut down the whole idea based on the perceived lack of usefulness which I consider simply incorrect. Oct 10 at 20:17
  • 1
    [3/N] @BernhardBarker that's exactly what I disagree with - an assumption that it is going to add noise for 99% of users. Both in terms of actual ratio and that it is actually going to be noise. I also do not, for the most part, have a brawl with more in-depth points of your answer, and many concerns I do share too ( especially if this feature is needed that much outside the Trinity ). And, frankly, the only problem I have is with the prominently featured unsubstantiated "1%". The rest was mostly a back-and-forth with Briam (who attempted to prove that it actually is Oct 10 at 20:28
  • 2
    [4/N] a real state of things in their response) and responding to the position which I also do not share - that something needs to prove its worth from a position of being considered "guilty until proven innocent" [note that it does not mean I think that if a feature is to be added that it should not have a justification behind it]. Other than that - I do not differ much in the assessment of concerns, just more inclined to think that it can be done right (and not that it is dead-on-arrival as some [not referring to you here] seem to think). Oct 10 at 20:36
  • 1
    @OlegValter Sorry for disturbing your intended break. I actually hope the feature is implemented, because I think that is the best way to learn something about it. But we should also keep a realistic view. It's a lot of work and may or may not pay off in the end.
    – Trilarion
    Oct 11 at 8:36
18

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 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 review queue available to the users with some experience in the tag. I would probably include all tag badge holders.

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

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

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 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 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 answer might no longer apply to some new version, 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.

3
  • 7
    "Flagging": only if that goes into a review queue! Mods can't and shouldn't have to see this at all. Domain experts do. Oct 7 at 20:14
  • 1
    @AndrasDeak Yes, I agree with that. I have no idea why I wrote possible - I never wanted to imply that moderators should handle those. Oct 7 at 20:15
  • 2
    I had similar thoughts as your "considerations" section - specifically version ranges (the "all versions" is like an open ended range). Oct 8 at 14:11
14

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.

6
  • 9
    That sounds a bit like jQuery answers in Javascript. When there is a popular library to do many tasks, but there are also good reasons if you might not want to use that library. Oct 7 at 19:48
  • 1
    This answer somehow manages to make a bad feature worse. No, we don't need tag on answers, we barely are able to make tags on question somehow work.
    – Braiam
    Oct 7 at 19:48
  • 5
    The feature is not about numeric versions, and the feature is not about categorising answers in general. It's about tackling upvoted, outdated answers. Oct 7 at 20:15
  • 3
    Fair point, @Andras, but it certainly could be used for those more general categorisation tasks. OTOH, the more complex a feature becomes, the harder it is to learn, and the greater the probability that it gets used incorrectly. We want it to reduce the chaos, not increase it. ;)
    – PM 2Ring
    Oct 7 at 21:05
  • 3
    @PM2Ring It is not necessary that a tool be complex for it to be general purpose or flexible. Sometimes designing something for too specific a purpose makes it needlessly complicated.
    – ColleenV
    Oct 7 at 21:55
  • 1
    @ColleenV Agreed. Hopefully, the info being gathered on this page will lead to a good flexible tool that won't confuse the newbies, the regular users, or the casual browsers.
    – PM 2Ring
    Oct 7 at 22:01
14

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 be. 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 for some there might. Check for yourself, if you think it would actually be worth it.
0
12

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 or ... 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 or , 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 and now.

1
  • 6
    I wouldn't remove version labels from questions. This is the version OP asked for and often it can be critical information for answering the question. However, problem the question asks about can be of more general nature and can have different solutions in different versions and answers can include answers for other versions than the original asked in the question. Question version should be completely independent from answer version. Oct 8 at 17:31
8

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").

3
  • 2
    It probably should mean that it's not known (especially the end-point of a supported feature might simply be unknown), but in practice the temptation will be big to interpret it as does not work outside the range and that's what people will think. After all, if you're not sure if a version label is accurate, why using it at all. On the other hand one could probably sort by version and then show first answers that definitely are for this version and then show others that also might be for this version (all who weren't originally for this version).
    – Trilarion
    Oct 10 at 19:47
  • @trilarion well, as far as I can see the filtering mechanism already treats it as an accurate range ... Also "not known" is hardly actionable, it would actually be quite useful to filter out outdated answers (old, deprecated versions) by default, providing a way to "travel back in time" (pick an old version). Oct 10 at 21:03
  • 3
    For example if it would mean "does not work outside" an answer using e.g. an IIFE to closure a variable in JS could be tagged as * -ES5, whereas a new answer using let could be tagged ES6- *, and by default the old hacky way would be filtered out. Folks who still need to support older browsers can change their filter to ES5 Oct 10 at 21:06
7

I think there should be a way for moderators to "lock" certain tags to prevent labels from being created (I mean, 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 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 and using a browser tag or version-specific browser tag is sufficient.

4
  • 2
    What this makes me think of is the concept of "hierarchical tags" or "tag inheritance". It's rarely mentioned and I can't image what it would look like, but it's an intriguing idea. (Probably still beyond the horizon of events at this point...But it could be the next game changer, who knows?!)
    – bad_coder
    Oct 11 at 10:44
  • @bad_coder I think this exact proposed feature (answer version labels) is what it would look like. In a large way it already works the way that MSO post suggests (it only considers a question a eclipse-3.5.1 question if it's tagged with that).
    – TylerH
    Oct 11 at 19:41
  • if they throw in a GUI with a tree, nodes, stems, leaves and a root, count me in! (I'm a sucker for eye candy.)
    – bad_coder
    Oct 12 at 0:19
  • 1
    @bad_coder If all else fails, you could just always gaze at this user's profile image if it's trees you want.
    – TylerH
    Oct 12 at 2:16
6

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.

3
  • 10
    They will default to being open ended (ie: version 2 and newer). You will also be able to make them be a range (though will probably always be inclusive, to avoid confusion). Ordering relation managed in the management tools for the tag versions, described above.
    – Yaakov Ellis StaffMod
    Oct 10 at 12:57
  • 1
    So "chronological order" doesn't mean according to the tags' creation date, and it should have said "version order" there? Oct 10 at 13:01
  • 2
    The use of [ and ] for inclusive and ( and ) for exclusive makes the range explicit. There's evidence of this style/syntax in the wild (e.g. NuGet). This would be nice, especially as more and more of the industry is buying into SemVer. I think this would still work with chronological ordering.
    – Kit
    Oct 12 at 11:53
5

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.

2
  • Hmm, a small banner above or below the label section indicating "Warning! Currently disputed" or something? That might be good.
    – TylerH
    Oct 8 at 16:05
  • 1
    Yeah something like that @TylerH. Or perhaps an orange triangle icon with an exclamation mark, that has a pop up.
    – Luuklag
    Oct 9 at 6:35
5

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).

3
  • Gating this behind silver tag badges pretty much restricts it to being a StackOverflow-only feature. Of the three non-SO sites most likely to benefit from this (ELL, Law, and Code Golf), ELL has only 85 silver tag badges (none of them in dialects) and Law has only 37 silver tag badges (16 of them in jurisdictions). Code Golf has 412 silver badges, but none of them in languages. If this is going to be a network-wide feature, it needs to be gated behind bronze tag badges at the most.
    – Mark
    Oct 9 at 2:28
  • 1
    @Mark It's true my thoughts are about Stack Overflow as that's the site I'm most familiar with, the biggest site on the network, and the site most likely to benefit from this. However, thresholds can fairly easily be adjusted for different sites. There's a lot they do for SO that doesn't apply to other sites already, because the opposite effect would occur for SO if you gated it lower there... everyone and their mother has a bronze badge in something, and that group regularly makes problematic contributions via user moderation on SO.
    – TylerH
    Oct 9 at 19:29
  • 1
    @Mark That being said, silver badges on other sites would still widen the pool beyond gold badge holders and moderators, which was the suggestion in the question above.
    – TylerH
    Oct 9 at 19:30
5

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 answer can indicate, if it was tested on newer versions, without editing answer itself.

New contributor
Dima Rostopira is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
3
  • How would this feature helps if people don't even tag their questions? Trying to understand your use case.
    – Braiam
    11 hours ago
  • @Braiam sometimes I find question to answer, only to try it and then google "how to do X on Android Z?". Take ANY question about files and Android 11 for example 11 hours ago
  • You are saying about answering question, this feature is meant for readers.
    – Braiam
    9 hours ago
4

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?

9
  • 2
    I agree with that. I would probably extend that to silver badge owners in tags where there are no gold badge owners or there are only few. Versions are not tags and if not handled properly it can easily result with a mess. Oct 8 at 11:00
  • Added value is in ability to search answers related to version. And I don't just mean locating them on the question page, but more general search where you could narrow down results by adding version (range) you need. Oct 8 at 11:07
  • 5
    I have a bit of a problem with restricting labels to gold tag holders. Having a badge for answering a lot does not mean one is more capable of curation or categorization (as shown by a lot of valid complaints about the behavior of gold badge holders of some tags on SO, for example). For the rest it means either compromising quality/curation activities or not being able to participate. If we are building a feature from scratch, please do not restrict it to badge holders (I suppose silver/bronze suggested above is more reasonable but ultimately suffers from the same issue). Since the [1/2] Oct 8 at 11:12
  • 1
    [2/2] is being built from scratch, how about giving to those who actually participate in tag curation already? Like a certain percentage and/or quantity of approved suggested edits on tag wikis/excerpts for those who do not have the privilege of unilateral edit (the vast majority of users, btw) and gold/silver/bronze badge for those that do (after all, what does it matter that user X has 20K rep if none of it is related to the tag they are versioning)? Oct 8 at 11:15
  • @OlegValter Restricting the feature in the beginning would prevent large scale issues until feature is not polished and some early workflow issues settled. Once we have good workflow, some restrictions could be lifted. Oct 8 at 11:21
  • 5
    @ResistanceIsFutile well, you see, I do not want restrictions to be lifted - it is a good idea to limit who is going to be able to create versioning labels, just not the gold badge holders, please. And there is nothing more constant than "temporary" :) Anyways, I wholeheartedly disagree with Dharman's assumption here that gold badge holders know better than, I quote, "inexperienced users". Not to mention that I do not see anything "temporary" in the answer - it clearly states that no one except mods and gold badgers should have this ability. Oct 8 at 11:24
  • @OlegValter If not gold badge holders then who? I know I can make version labels in some tags where I am not the expert, but I am also sure that gold badge holders should be able to that job, too. If someone starts abusing, they can be easily suspended. Oct 8 at 11:32
  • 4
    @ResistanceIsFutile I already proposed that in my first comment :) An actual actionable analysis of whether or not someone is invested in and can categorize properly. You can throw in gold badge holders for good measure but my specific brawl is with the "please never let anyone else". I also have to note that the ability to suspend should not prevent us from making more robust systems from the get-go. Oct 8 at 11:46
  • 2
    I agree a higher bar is good, but I think we can let silver badge holders in on the fun as well. As someone else answered, there are many tags where there is only one gold badge holder or a very low incidence of questions, meaning it can take years for someone to earn a gold badge.
    – TylerH
    Oct 8 at 14:56
4

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.

4

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).

3
  • 6
    Answers that include multiple version should include tags for all the versions that apply, and then indicate in the answer which section applies to which version. That way users can still filter to the answers that they need. Including the syntax inline as you suggest is somewhat of a nightmare in terms of things like permissions for version creation, version merging, search and filtering, preventing abuse, etc, and is just something that we are not going to do. And I view hiding the feature from users as a negative, not a positive.
    – Yaakov Ellis StaffMod
    Oct 12 at 10:47
  • See also this answer from yesterday (same question as yours)
    – TylerH
    Oct 12 at 12:48
  • @YaakovEllis I was not suggesting to change anything about tag creation permissions, search, filtering etc - those work normally. I would just do linking the tags inline, like I can currently do [doesnt-exist], without the permission to create it. You might be right that version merging is a problem, but not an unsolvable one - you might even do edits by the community user or something. (And IIRC, renames and synonymisation of question tags already has the problem that the posts are not updated immediately but only on the next edit, then showing up in the history diff).
    – Bergi
    Oct 12 at 18:17
3

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.

8
  • 2
    How about removing the version from the question and answerers decide whenever or not mentioning that their solution targets a specific version (and somehow manages to not work on any other version) themselvers?
    – Braiam
    Oct 7 at 22:03
  • 3
    Answers about versions not specified in the question could still be useful to future visitors that have the same question but for a different version. Therefore such answers should be allowed in general, also to prevent the need for (topic-wise) near-duplicate question-answer pairs where only the version differs.
    – Marijn
    Oct 7 at 22:04
  • 2
    @Braiam What if the problem in the question is only seen in a specific version?
    – GoodDeeds
    Oct 7 at 22:31
  • @GoodDeeds are you sure that there has been a question that only applies to X.Y.Z version and not to +/-1 versions? I would really like to see that example, and I expect that it was a bug that only lived for a short while.
    – Braiam
    Oct 8 at 11:05
  • @Braiam I didn't say that the problem should apply to just a single specific version, I was responding to your suggestion of removing version information entirely from the question. Even if it applies to a set of versions, it is useful information to include in the question for reproducing the problem.
    – GoodDeeds
    Oct 8 at 11:11
  • A question asking about "the latest" version of PHP is still asking about a specific version... they just didn't explicitly state that version. Because we know the release dates of different versions of PHP, and we know the date the question was answered, we should edit the question to say the explicit version. As far as answers that cover newer/future versions of PHP, I'd probably allow them unless OP mentioned specifically sticking with this version and not being able to change it (e.g. working with embedded software that can't be upgraded easily later).
    – TylerH
    Oct 8 at 14:55
  • 1
    We already allow that on SO. When a popular question is applicable to a range of versions, it tends to get answers for all those versions, with varying levels of comprehensiveness, even when the question was tagged with a specific version. I think the appropriate reaction is to remove the specific question tag and label the answers with what versions they apply to. The only difference now is that there's a different way to label answers.
    – Laurel
    Oct 9 at 14:01
  • Again, what usefulness has the future reader that the question only applies to 1 version of the software?
    – Braiam
    Oct 9 at 17:50
3

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 future to solve the outdated version tag problem.

1
  • 3
    You will not be required to label the version on an answer. If you do, it will default to be "that version and newer". And if this stops being true, then someone will need to update the version tag (the same as would need to be done on an answer). There is no way of automating this, but hopefully by making the labeled versions more visible and discoverable, it will also expedite the curation process in this aspect.
    – Yaakov Ellis StaffMod
    Oct 13 at 20:16
1

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.

16
  • 1
    It's not always easy (or practical) to write code that spans multiple versions. I did adopt that approach for a couple of years with Python, but I'd often end up posting separate Py 2 & Py 3 versions (in the same answer). Often, the compromise code is much less efficient (&/or harder to read) than the version-specific code. Or it's perpetuating a bad practice that the new feature was specifically created to abolish. I know for a fact that some top Python answerers adopted a policy of specifically writing code that only works on Python 3, to encourage people to update.
    – PM 2Ring
    Oct 7 at 22:31
  • 6
    I think this answer misses the problem being addressed, which is that old, outdated answers often have so many upvotes that they never get pulled down from their top spot. Many people only look at the top answer, and end up using the outdated answer, rather than the newer, best-practice answer. Most outdated answers still work, but they are no longer best practice, or have a security flaw, or whatever. Oct 7 at 23:26
  • 3
    @PM2Ring I am not proposing that code should be written to span versions (unless that is how an answerer prefers to structure their answer). Instead, if an answer contains code for different versions and version ranges that code should be separated by versions and version ranges and optimal for each.
    – PolyGeo
    Oct 8 at 0:03
  • 2
    @CrisLuengo I think you are highlighting a voting behavior problem which is that relatively few viewers of Q&A vote at all, and when they do many have a reluctance to downvote and answer even if they find it personally to be not useful. Now that accepted answers are no longer pinned to the top it becomes important to make sure useful and not useful answers float to the top and sink to the bottom respectively by voting as often as practicable.
    – PolyGeo
    Oct 8 at 0:07
  • 1
    @PolyGeo Indeed, many people are reluctant to downvote, unfortunately. But the vast majority of readers either don’t have an account, or don’t have the rep to downvote. Oct 8 at 2:43
  • 1
    There are technologies that are used across large span of time, where answers to old versions are extremely valuable to people that are still using them. Downvoting good answers just because they cover older technology is bad practice. We should only downvote bad answers, regardless of the version. Also, with massively upvoted answers, downvotes don't solve visibility problem for answers covering newer versions. Answer labels allow finding appropriate answers faster, without the need for downvoting something just because it is old. Oct 8 at 8:01
  • 1
    @ResistanceIsFutile Version labeling is a long term complex solution. Voting behaviour is a long term simple solution. Voting guidance on answers is about usefulness - presumably current usefulness.
    – PolyGeo
    Oct 8 at 8:31
  • 2
    If I mark old highly upvoted answer with appropriate version today, how is this long term solution? If I downvote such answer today it may never fall back even after a long time. Again, two people coming to same question can find two totally different answers useful because they have to work with different versions. Why would I downvote good answer just because it does not cover version I am using. This makes no sense to me. Oct 8 at 8:35
  • 1
    @ResistanceIsFutile Long term because of the massive number of answers to version label accurately. Newer answers will only start to float towards the top as new version users start to outnumber old version users. Personally I try to use newish to latest versions of software so it is those answers that I personally find useful and will tend to upvote.
    – PolyGeo
    Oct 8 at 8:45
  • 1
    I left a comment on Braiam's answer. Not all versions are about software version you are using. It may be about OS API, where you will have to support various versions. Yes, it will take time to mark all answers, but if every users starts labeling their own highest scored answers (that can usually be done rather fast), this can become useful feature very fast. Oct 8 at 8:50
  • 1
    @ResistanceIsFutile I think the proof will be in the pudding. I remember how appealing SE’s Documentation sounded at the outset but how impractical it became when implemented.
    – PolyGeo
    Oct 8 at 8:56
  • Documentation fell to pieces for many reasons and most of the problems could be anticipated from the start. The only possible way labels can fail, is if people start abusing or adding wrong labels - but that can be solved by labeling suspensions. Or in case of serious abuse account suspension. Oct 8 at 9:05
  • 1
    @ResistanceIsFutile you forgot the most important way labels can fail: people don't use them at all. The same way as voting.
    – Braiam
    11 hours ago
  • @Braiam Well, we cannot predict the future, so anything is possible, I just don't think it is very likely. Also what is the worst that can happen if labels are not used? Everything will stay just as it is. 11 hours ago
  • 1
    @ResistanceIsFutile considering that we already have an example (version on questions in at least two sites like Ask Ubuntu and Drupal Answers), they are used extensively and the usage just falls off a cliff when people move on to the next version or when there's less breaking changes between versions. Example, due how drupal started to settle the api after version 8, version tags passed from the most active tags to the least used tag. Tag 9 despite existing for 2 years, haven't been able to surpass the 8 tag question per day.
    – Braiam
    9 hours ago
1

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

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

10
  • 6
    In such case, you would just change answer's version label to include additional version and label new solution within answer's text. Once you have located answer that supports some versions, it is not that hard to read the whole answer and use appropriate solution. Oct 11 at 9:43
  • @ResistanceIsFutile then why add such complex feature if everything will be written in text itself anyway?
    – Kos
    Oct 11 at 10:14
  • Because you need to locate appropriate answer first. Answers can span through many questions, it is for narrowing down pool of potential answers to begin with. Once you are looking at some answer and it covers few versions, you can easily locate text within the answer that covers that particular version. Of course, that still means answer needs to clearly state what solution is appropriate for which version, but such answers most commonly do. Oct 11 at 10:18
  • 1
    @ResistanceIsFutile I still don't get it why we need labels then, but hopefully there will be a solution that will work for most of users.
    – Kos
    Oct 11 at 10:32
  • 1
    Finding "How to do X" in particular version is like finding needle in a haystack. Answer labels for which versions it works, so having that label will help you to find sewing kit in the haystack. Once you have found sewing kit is is easy to locate the needle. Oct 11 at 10:40
  • 1
    Labeling part of an answer sounds unnecessarily complex both in implementation and in understanding as a reader. Either an answer should have a range of version labels and use a header in their answer to indicate which parts work for which versions, or they should post a different answer for a different version.
    – TylerH
    Oct 11 at 19:29
  • @TylerH yes sure, let's blame authors for posting their long answers for all possible solutions
    – Kos
    Oct 11 at 20:38
  • @Kos Who said anything about blaming people?
    – TylerH
    Oct 11 at 20:41
  • @TylerH well, the way you see this feature puts serious restrictions on authors, but no real value to users as now they have two answers from same author, possibly having some common parts. Value of such posting is lost forever.
    – Kos
    Oct 11 at 20:46
  • 1
    @Kos There is no value lost here; you can label a single answer with a range of versions and use ### headers to identify which sections apply to which version. Nearly identical outcome to your suggest with none of the extra implementation effort.
    – TylerH
    Oct 11 at 20:47
-2

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.

28
  • 20
    I disagree. There is plenty of technology where answer for one version does not work in the other and where version is important. I have seen plenty of highly active questions with answers added over time that cover new versions and new capabilities and where old answers still carry a lot of value. Usually such information is edited into answers, but it would be far easier to search for appropriate answer if you don't have to look for the information within the answers. Oct 7 at 20:10
  • 6
    Seriously? For example, there are major differences between Python 2 & 3, particularly in Unicode handling. The transition between versions took a decade, and there are a ton of old questions without a version tag. Sometimes, the OP's code or problem description makes it obvious which version they used, but not always. So anyone reading those answers needs to do some detective work. If they're lucky, they'll copy some code that will fail with an error message (that they may not understand). Or the code might run but do the wrong thing...
    – PM 2Ring
    Oct 7 at 21:35
  • 6
    JavaScript is a great example of where this is useful. ES6 changed JS hugely, and you'll quite often see ES6 and non-ES6 answers on a large number of questions where it added a better way to do what was previously difficult to do. Oct 7 at 22:15
  • 2
    It's relevant because it can cause problems if you don't know what version the answer code is. Admittedly, if you're familiar with both Python 2 & 3, and what the differences are, it's generally not that hard to figure it out, but it does take some detective work. But a new student, unfamiliar with Python 2, may have difficulties. In fact, there was an example of that a few days ago on MSO, involving bytes vs str (which has since been deleted). And conversely, there are people using legacy systems stuck on Python 2 who cannot use Py 3 stuff.
    – PM 2Ring
    Oct 7 at 22:16
  • 1
    I expect that this sort of thing happens a fair bit. A new Python 3 student with a fairly basic problem does a bit of a search & finds a relevant high scoring answer on an old canonical question. But it doesn't work for them because it"s actually unmarked Py 2 code. So they ask a fresh question, without mentioning their prior research. A few minutes later, their question gets dupe-hammered to the canonical that they already looked at. If they're lucky, there's a low-scoring Py 3 answer on that page...
    – PM 2Ring
    Oct 7 at 22:23
  • 1
    @PM2Ring The reason the transition took a decade is because people are stubborn and just refused to upgrade. The transition really wasn’t all that hard. Oct 7 at 23:29
  • 2
    @CrisLuengo Agreed. But we're left with a huge number of questions posted during that transition period, many of which don't have clear version info. Sometimes, that's not a major issue, but sometimes it's vital, eg, with Unicode questions. Of course, you can't really write a good answer to a Unicode question without knowing the version, but there are many suboptimal answers...
    – PM 2Ring
    Oct 7 at 23:48
  • 3
    TypeScript does some extreme changes to how common problems are approached too. We have a lot of superb answers from core language contributors struggling to maintain a clear indication that half the answer works in 4.3 but does not in 4.4. Or vice versa. Or a combination of both. And it is not 1% that uses an "ancient" version that came out 5 days ago. Good software does not mean backwards-compatible. Oct 8 at 1:08
  • 2
    It is not just about tools. Version can be anything. What about OS API? Some APIs change and cannot be used any more. You can have situation where you need both support very old API and new API in your application. You may find multiple answers useful. Labels enable you to find and filter answers by your needs faster. If I find old answer, flag it or change its version, I am leaving useful artifact for future visitors. With time it will get easier and easier to locate appropriate answers. Oct 8 at 8:41
  • 3
    Just because you never needed something does not mean others didn't have such need. Oct 8 at 11:10
  • 1
    @Braiam I am not questioning you ability to write answers to hard questions. I am saying that not all technology is the same and has same requirements. I know that versioning would be immensely helpful in some tags I am participating. Not only for writing answers, but way more for finding answers. When you are looking for solutions and search gives you 20+ questions with 10+ answers narrowing down those based on particular version would be immensely helpful. Oct 8 at 13:37
  • 1
    We are going in circles... I already said that searching in text is not good enough. I have to open 20+ questions to find whether it has answers for version I need. If I search how to do X in Android, I need to cover anything from API 19 to API 30, and there might be four ways to do that in between and I know how to do that for two. I need to find the missing pieces in range 22-26 and 28-30. How do I do that effectively without having answers versioned and ability to search through multiple questions with version range? Oct 8 at 14:15
  • 1
    I also have to mention that an obvious problem with free text here is that everyone does that however they please. At the start, at the end, in the middle, as a footnote, supercased, subcased, bolded, italicized, formatted as code, as [tag:<name>], you name it. Having a standard way (hopefully a convenient one too, but that's an implementation detail) is a clear-cut solution to that. It also removes the mental strain of looking these things up that can be anywhere (sometimes only in comments), and anything that does so already is more valuable than plain text. Oct 8 at 14:29
  • 1
    @OlegValter "...It also removes the mental strain of looking these things up that can be anywhere (sometimes only in comments), and anything that does so already is more valuable than plain text." I fully agree that annotating text semantically gives advantages but in this case there is also a disadvantages of placing version tags outside of the text. I rather like them in the text, because the position usually matters. It's actually more readable if the version tags could just be anywhere in the text and then would also be gathered from it and summarized below the post.
    – Trilarion
    Oct 12 at 6:08
  • 1
    @Trilarion not sure I understood your point (honestly), can you clarify a little bit on the last bit - do you mean that you see merit in placing them anywhere but having a summary at the bottom of the post (which is probably where I would've put them too, at least to align with how tags are positioned on questions)? On a tangential note, most of my response above is a refutation of Braiam's point that one can "use text" already that disregards the simple fact that plain text and dedicated functionality have different meaning and "weight" (in terms of impact). Oct 12 at 15:02
-3

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.

5
  • 7
    It's going to be opt in regardless. Many sites likely won't need this feature.
    – Catija StaffMod
    Oct 8 at 13:15
  • 1
    @Catija the announcement doesn't specify that. Can it be included?
    – Braiam
    Oct 8 at 13:24
  • 1
    Unix & Linux did not "remove version tagging". We only removed tags for versions of the same distro. This is not a general ban on version tags, not when there are significant differences between versions. We still have (and want) both a grub-legacy / grub and a grub2 tag, and still have gnome and gnome3.
    – terdon
    Oct 11 at 17:14
  • 1
    @terdon considering that the same argument that applied to distro version tags also apply to those two sets of tags (which btw, I think are the only ones left that use versioning), I would say that there has not been just enough will to merge them too.
    – Braiam
    Oct 11 at 18:59
  • 2
    The point is that you are completely misrepresenting the situation. U&L did not "remove version tagging" in general. It simply merged one specific case of tags about distribution versions into single distro tags. That wasn't a general thing about versions, it was very specific to that one class of tags so it should not be presented as "this site removed version tags" as that is not true.
    – terdon
    Oct 12 at 11:15
-4

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

  1. (...) 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .