lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl <>
Subject Use of JIRA fixVersion
Date Sat, 01 Jun 2019 18:58:03 GMT

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

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


View raw message