The main use I've had for this field: as a user, I want to know whether this bug or feature has been fixed or is available in the version I am using, and if not, which version I would need to upgrade to in order to get it. For this use case I think it's important to list versions on each branch it has been ported to, up to the first major version release that included it.
That seems to be at odds with the use case of automatically generating the changes file, where we want to pick a single branch. Both seem important, and I hope we can find a way, maybe by using some additional field, to support both. I don't have any productive suggestion how to do that, sorry, but just wanted to be clear about what we are trying to accomplish. Did I capture it? Here's an idea: could we choose the highest branch that is not a .x branch as the fix branch for the purpose of the changes file? On Sat, Jun 1, 2019, 2:58 PM Jan Høydahl <[email protected]> wrote: > Hi > > This topic has been discussed several times before and various projects > practice different rules for the fixVersion field. > > Reason why I bring it up again is that I was researching the use of Yetus > releasedocmaker[1] for generating release notes based on extra info added > to jira issues as they are resolved. Attempting to run the tool for Solr > v8.0.0 ({{releasedocmaker --project solr --version 8.0}}) resulted in a > list of 255 features, but only 30 of those were actually new in 8.0! > > Currently we tag issues with fixVersion before commit, to indicate what > BRANCHES we intend to commit to, i.e. new features normally gets “master > (9.0)” and 8.2, while bugs normally gets 8.1.2 in addition. More serious > bugs and security issues may in addition be flagged with 7.7.2. > > An alternative fixVersion policy that I’d like us to consider, would be to > mimic how we add CHANGES entries, i.e. only record the first version where > a feature is introduced. For bug fixes we also in addition record any > version where we backport the fix. This is because there is not a strict > time line with increasing versions once a release has happened in a newer > major version branch. I.e. once 9.0 is released we cannot guarantee that > 8.x.y is released before 9.x, so both need to be recorded. With this > strategy, the only time it would make sense to have fixVersion=master(9.0) > for a bug is if a bug in the 8.x line will not be fixed in a 8.x feature > release. but the first fix will be in 9.0. With such a use of the field, a > report for fixVersion=9.0 would list only new features and new bug fixes in > 9.0. If we later change our mind and backport to 8.x we’d need to move > changes entry and fixVersion from 9.0 to to 8.x. > > If we switch to this policy you could not immediately see from jira > whether a feature or bug fix perhaps only applied to 8.x and not 9.x. So > we’d need some other way to see this. Three ways spring to mind: from yetus > comments, from git log or from a separate jira field. > > Another discussion that keeps coming back is when to add fixVersion in > jira. Some argue it should not be added only when you actually push to a > branch. But most of us add it based on intended (hoped) version before > development starts. Should we write down a formal policy on this? > > Jan > > [1] https://yetus.apache.org/documentation/0.10.0/releasedocmaker/ >
