On some topics, I want to limit my queries to a specific version of either a programmimg language, library, or framework. This happens most often with fast-moving open source projects (angular, ember, rails etc...) and would only be applicable for certain tags (maybe moderator rights to select). I know the common pattern is to have a separate tag like ruby-on-rails-3, but this is a bit ugly since it require massive duplication and more importantly missed when somebody tags something ruby-on-rails-3 and you only search ruby-on-rails. I don't think this is a feature that would be applicable to most tags, but for certain fast moving apis, it would provide more information than is currently available and reduce duplication. I'm thinking this would be something that could co-exist with current tag system but use user-participation to make work better. I think as SO gets older this becomes more and more of an issue (ie looking at 5yo Rails questions can be interesting... and this problem will just get worse). This is probably relevant for like 10% of topics here.

In terms of how this could be implemented, the asker would select ruby-on-rails and her version for the question (lets say 3.2). Somebody (either an answerer or reader of the question) could then either expand the range of applicability of the question (say for rails it is applicable from 2.2 to current). This way the scope of the applicability of the question and answer could be specified very explicitly and outdated answers could be made explicit.

I think this would also help the question asker by reminding them to specify which version of the framework they are using. Also, the more I use the search features, the more I would like to use operators for only Ruby on Rails >= 3.2. It seems managing this at the actual tag name is ugly. This could be done over time and could coexist with current tags.

(I have the feeling this has been asked / suggested so feel free to point to the discussion but I couldn't find it. I see this and Jeff's answer here as closest to addressing: When is it appropriate to have minor version numbers for tags?. The gist of his argument is that version specific tags should only be used when the topic in question is specific to the question.)

  • So, what are you asking? Is there a proposal in here somewhere, or a question about what the current policy is, or what? – Servy Dec 19 '13 at 17:09
  • it's meta right? is there a way to do this? If not, would it make sense to do so. see metahistory – timpone Dec 19 '13 at 17:10
  • This might be a duplicate of meta.stackexchange.com/questions/78522/… except I can't actually tell what that question is asking for. In principle I like the idea of semantic metadata added to tags to make searching for specific ranges of versions possible, but I can't imagine how to implement that in a non-awful way (and I also can't imagine the SE devs agreeing to implement it in any way at all.) – Wooble Dec 19 '13 at 17:18
  • I think the idea I was getting was the user could specify which version they are on at time of asking (in case of RoR - say 3.2). So rather than select both ruby-on-rails, ruby-on-rails-3, ruby-on-rails-3.2, they'd just select ruby-on-rails and 3.2 from a drop down. Perhaps, a person who answers could then extend the min version that it should be applicable and also a max version. So for example, if it's something that has been in RoR since 2.2. they would extend it back the start version to 2.2 and the end version to current. The person asking will not know cont... – timpone Dec 19 '13 at 17:31
  • since they are asking the question. This would allow a searcher to then search only questions that are valid for their use version (I'm on RoR 3.2 so don't really care about 4 or something retired in 3.0). So question asker specifies his / her version and over time the version can be extended down to a start and up to a max when the answer would be no longer valid (and could also be specified as current). – timpone Dec 19 '13 at 17:32
  • @Wooble reading through some of the other tagging ideas, I think the idea of creating some heirarchy or synonym is totally off. It seems like there's no shortage of users who like to view, comment, characterize questions and answers. That dynamic should be utilized and not trying to OOP / symlink a tagging system. I really see this mostly with API's that change over time but that does include many popular open-source frameworks. Also, as SE ages, questions become invalid which a system like this could also support. – timpone Dec 19 '13 at 17:45
  • +1 this may be helpful at times. – n00b Dec 20 '13 at 20:14
  • This would also help improve the "latest" problem (see the "About Me"). Perhaps if version numbers were an optional subset of tags; I could have ruby-on-rails and ruby-on-rails-v3, where both would show up in a search for ruby-on-rails, but it could be narrowed down to versions for people looking for their specific problem. – Trojan Dec 27 '13 at 23:38
  • @trojansdestroy agreed about tag polution and versioning – timpone Jan 3 '14 at 23:26

You can use a star in the search, I mean you can search for [ruby-on-rails*] to get posts related to any version of ruby on rails.

  • Thx, didn't know it supported wildcard. In terms of current concept, that's a bit the opposite of what is trying to be achieved. You really want to return answers that would only be relevant not any answer. – timpone Dec 28 '13 at 1:05

This would lead to a lot of unnecessary complication. Many askers are not yet competent enough to tell whether the version number of their programming language / framework / library is relevant to the question. Not all programming ecosystems differ as massively from version to version as Ruby on Rails seems to. Often, version jumps do not have any bearing on the underlying programming language at all.

At the moment, version specific tags are created by the community, where they can be discussed and moderated based on the consensus that is reached. Version specific tags get created when they are meaningful.

Good answers by informed users will automatically take version differences into account. That's part of what makes them good answers.

I don't think we should depart from that model.

  • thx for answer. hmm... i don't see this as competing but rather complementary and of all the frameworks I work with rails is the most stable. Underlying language is a totally separate issue but I've seen c questions where very different c99, ansi, or c11. The important point is that version relevance doesn't need to be added by the person asking the question. Answerers can't future proof their answers. I see it more as normalization to version rather than perceived meaningfulness. – timpone Dec 28 '13 at 1:08
  • @timpone but the version information will not be meaningful in all cases, by far. At the moment, the community uses tags to separate questions where applicable. I don't think that is working so badly. – Pëkka Dec 28 '13 at 1:12
  • The problem is that tagging doesn't scale. To take the example of a rails-3 question that is current through a hypothetical rails-5. People would have to be retagging it to all the different versions (ror-3, ror-3.1, ror-3.2, ror-4, ror-4.1, ror-4.2, ror-5) where you really want ruby-on-rails v3-current. In current incarnation, I would agree that that it's not working so badly but I think this aspect could be improved. – timpone Dec 28 '13 at 1:18
  • @timpone I see what you're getting at, and I'm sure it would be very useful in some tags. But it would introduce huge new levels of complexity, and then you'll have exceptions and special rules and situations where it applies only to version 4.1 and 4.3 but not 4.2.... no, I think a good answer needs to take versions into account. And for new versions, the idea is that existing answers can be edited, or new answers provided as time progresses. – Pëkka Dec 28 '13 at 1:20
  • well, if we're getting into not applicable to internal versions, that would be pretty extreme (and prob a bug in language or framework). I'm not proposing that at all but could see how something like that could be handled by an edit to another question. I think this would add a fair amount to evergreen answers to show that they are current. The UI would obviously have to be worked out. – timpone Dec 28 '13 at 1:25
  • @timpone but who would update the questions whenever a new version comes out, one by one, and determine whether they still are current? Stack Overflow currently has more than 5 Million questions. – Pëkka Dec 28 '13 at 1:27
  • I was thinking user would specify his / her version. and a reader / answerer could update where works for them in their version (with a notion of starts / ends). I would imagine that it would be reasonable to set end as "current" until it doesn't work anymore and users would push back "start" to when it doens't work. Agreed about number but for evergreen type questions (>5k views), it would be of benefit. If people dont' update, it's not much different from current system. Would never expect all 5M to be tagged in this way (nor would it they be relevant). – timpone Dec 28 '13 at 1:31
  • so take this question: stackoverflow.com/questions/15558992/… even though it's closed, it gets viewed a lot because people get that exact error and the answer (which I added) works. However, this answer isn't relevant to AFNetworking 2. It seems like SO should provide a tool that this question is not relevant. – timpone Dec 28 '13 at 1:54
  • @timpone there are several options you can choose: 1. Edit the answer to state it's relevant only to a specific version. 2. Retag the question (if applicable). 3. Suggest the creation of a afnetworking-1 and a afnetworking-2 tag on Meta. 4. Add a comment underneath other answers highlighting their limitation. – Pëkka Dec 28 '13 at 2:21
  • I agree with the suggestions but I think those are a little ugly / time-consumting / prone to being inaccurate. Not trying to be argumentative but I think what I've proposed migth work better. Just a proposal. – timpone Dec 28 '13 at 2:42

You must log in to answer this question.

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