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/
