> -----Original Message----- > From: Giuseppe D'Angelo [mailto:dange...@gmail.com]
> On Wed, Feb 17, 2016 at 8:29 AM, Blasche Alexander > <alexander.blas...@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. I disagree. Sure you may not know whether there will be a 5.6.3 but you do know today that the following will happen: - git5.6.0 will be 5.6.0 - git5.6 will be 5.6.1 (sure 5.6.2 will be harder to guess and by all means use 5.6 for it) so far we always had a .1 patch release and I cannot see this changing. On top of that you know it is an LTS. - git5.7 will be 5.7.0 Alpha (unless we will never have 5.7 as a release version) - dev will be 5.8 Alpha Where is the open question in your mind about the above 4 cases? > 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? Use 5.6.1, there is no harm. We are 99% sure it will exist and even if it never comes about I will rewrite it to 5.7.0 when it is certain and I see the merge. After all the 5.5.3 release tag did exist as well till yesterday and they all got rewritten to 5.6.0RC because we had the last 5.5->5.6 merge. In fact Jira enforces this as we have to shift Jira release version tags into the "released" state. > 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). 5.6 is a temporary release tag. During the entire history of Qt in Jira it has been this way. Sure, if you aren't sure then by all means use it but be prepared that we might end up with a situation where it ends up with the wrong tag. An excellent example for this is https://bugreports.qt.io/browse/QTBUG-40060 . And yes, I could have tracked this case down but doing so for hundreds of Jira items is unreasonable. What matters when a Qt user looks at a bug is the ultimate release version for the Qt at hand. Do I need to upgrade from 5.6.2 to 5.6.3 or not? Just stating 5.6 is meaningless once the bug is in a released Qt version as the meaning of 5.6 shifts over time. 5.6.0 does not change its meaning ever. Also it is unreasonable to expect that customers have to dive through gerrit and git to figure out which release got the patch eventually. I certainly don't want to do that for gcc versions or the linux kernel releases. > 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. We all agree that a lot of things can be automated. Right now they are not and unless you volunteer to do this it won't get done. We all have priorities (including the release team which currently tries to manage 2 concurrent releases). Similar cases are change logs etc. In this case every developer has to set a FixVersion when resolving the bug. Is it too much asked to make an appropriate guess which might improve the accuracy of our data? It is hardly more effort for you as individual developer. If unsure you can use 5.x tag as always. -- Alex _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
