6

The question about "Upgrade from job-dsl to Jenkins 2 pipelines" contains these tags:

Even though does not have any tag details yet, I bet it has to do with some specific version (or should I say release?) of Jenkins.

If my educated guess is right, then my real question here is this: should we yes or no have on top of ?

For what it is worth:

  1. Personally I'm PRO version tags, for reasons I would be happy to repeat as an answer here also.
  2. Using version tags does NOT seem to fit with the common vision / recommendation of SE sites (my understanding: when old releases become unsupported and disappear, questions tagged with such version tag loose there value seen from an SE-business perspective).
  3. From some recent experiences in some other SE site, the "guidance from the mods over there" has been to try to only use version specific tags when really needed (the remaining challenge being "when do you really need it").

Now what, how can you make an actual decision about this topic to avoid future discussions (to not say battles ...) and mistakes ...?

Note: a variation of such tags is what got asked in chat.DevOps.SE about and .

1 Answer 1

Reset to default
7

Jenkins 2 bring a far different approach than previous Jenkins release did, I think Jenkins 1.x is still there for a while as porting jobs is not that easy.

So for this specific case I'd vote yes keep both and handle the re tag when necessary.

One use of the tags is to allow someone to follow the question he/she's interested in, someone comfortable with Jenkins2 actually may not wish to follow questions on Jenkins 1 because an answer based on Jenkins 2 may not be applicable on Jenkins 1 at all, and checking the compatibility isn't its scope.

Main idea should be creating a tag for a version where the changes are majority of the release. That doesn't mean each major release because a major release could be done for only one or two breaking changes, keeping the overall behavior identical.
For example Chef13 will come in April with a bunch of breaking changes, the 12.5 version did bring a change on how to tackle custom resources, but those changes doesn't worth a tag per version as the majority of features stay the same.

The cut on the "majority of the release" should stay a case by case basis discussed here on meta in my opinion.

5
  • 2
    Gggggggggrrrrrrrrrreat ... I mean "merci" ... for your answer. It's exacty the kind of answer that I predict future discussions about ... I think it fits with "my" preference (= bullet 1 in my question), but conflicts with the 2nd/3rd bullet. Oh well, at least we have a meta question ready already for whenever the issue arrises ... time for a walk!
    – Pierre.Vriens Mod
    Commented Mar 11, 2017 at 20:43
  • Versioning should not be allowed> Even with those differences. At the end OP or answer will specify the version
    – Romeo Ninov
    Commented Mar 12, 2017 at 15:58
  • 2
    @romeo Then there would be only python tag on SO, and no python2 and python3. Keep in mind one use of the tags is to let people comfortable with the subject follow it. In the case of Jenkins, someone familiar with Jenkins 2 only may not answer properly a question targeting Jenkins 1.x which may need a plugin for something native in Jenkins 2
    – Tensibai
    Commented Mar 12, 2017 at 20:19
  • @Tensibai, the use case you explain is IMHO exception, not rule. Following your idea we should have versioning for every major (ot even minor) version.
    – Romeo Ninov
    Commented Mar 12, 2017 at 20:22
  • @Romeo I forgot an important point, someone knowing he may miss something on question about Jenkins 1.x may wish to follow only Jenkins 2 questions. And yes, a tag per version where the changes are majority of the release. That doesn't mean each major because a major could be because of just one breaking change.
    – Tensibai
    Commented Mar 12, 2017 at 20:29

You must log in to answer this question.

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