On Wed, Feb 17, 2016 at 8:29 AM, Blasche Alexander <[email protected]> wrote: > > The verion tag 5.5 is not a proper version tag. A bug consumer would not know > where to find the fix. Issues should always be set to the most appropriate > fix version tag. If you know that git's 5.x branch will later be branched off > into 5.x.y then you should set it Jira to 5.x.y. The only case where the 5.x > tag makes sense is in a scenario were you don't know whether the 5.x branch > will still generate another patch level release. Once it is certain where the > a 5.x branch ends up I go through the 5.x release tags and they become the > next 5.(x+1).0 (RC|Beta|Alpha) or 5.x.y release.
I'm sorry, but this reasoning makes very little sense to me. The decision whether a given version will or will not be released from a branch belongs to the release team, and it's (99% of the time) just a bandwidth and packaging problem, i.e. "do we have enough resources to put 5.x.y out". A developer fixing a bug has no influence nor knowledge over that process; it's already enough of a burden to make patches target the right branch (*), as versioned branches come and go, overloading Oswald with "please move this patch" requests. Think of a bugfix landing in 5.6 right now. What's the tag I'm supposed to use? 5.6.1? What if there won't be one, and how am I supposed to know that (which by the way was exactly the case with bugfixes landed in 5.5 after 5.5.1)? Should I be conservative and use 5.7.0 then? So what happens if there is indeed a 5.6.1, people will think that it won't contain the bug fix? On the other hand, marking it as "5.6" is meaningful – whoever uses 5.6 from git knows they'll have the bug fixed. There are many downstreams which use specific branches from git (as for various reasons they can't "just upgrade"). If you think that "5.6" is confusing or not accurate, we could rename them, perhaps to "5.6 branch" or "5.6 git" or something like that (or use a different field on the report for this purpose). Next to that branch tag, you could add a specific version tag of the first released version of Qt that contains that bugfix. For the reasons above, it should be the job of the release team to do this, and luckily should be easily scriptable – for instance, by taking the SHA1 in the bug report and checking if the new release contains that SHA1, then tagging the report accordingly. (*) And we haven't discuessed yet how to tackle the LTS. But I rejoy thinking that for the next 3 years I'll have a automatic -2 if I spot bugfixes not targeting 5.6. My 2 c, -- Giuseppe D'Angelo _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
