[Development] How to find the most appropriate "Fix Version" tag in Jira

[Giuseppe D'Angelo]

On Wed, Feb 17, 2016 at 8:29 AM, Blasche Alexander
<alexander.blasche at theqtcompany.com> 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