Trying to reach a conclusion (or perhaps a vote) on this.

Here is a table that sums up my proposal. Basically it means in most cases stop adding master as fixVersion.

TypeCommitted tofixVersionCHANGES.txt section
Featuremastermaster (9.0)9.0
Featuremaster, branch_8x8.28.2
Bugfixmastermaster (9.0)none (unreleased bug)
Bugfixmaster, branch_8x8.28.2
Bugfixmaster, branch_8x, branch_8_18.1.2,, 8.2
Bugfixbranch_8x, branch_7_77.7.3,, 8.2

In addition to this, we should all wait until commit time with setting fixVersion.

To find branches for a JIRA, you just translate fixVersion to branch, e.g. 8.1.2, 8.2 -> branch_8_1, branch_8x. 
For features, if it is unclear whether master has the commit, check gitbot log or git log
For bugfixes, there are cases where the bug does not exist in master at all, and that can be reflected in affectsVersion field.

Jan Høydahl, search solution architect
Cominvent AS -

3. jun. 2019 kl. 19:56 skrev David Smiley <>:

Right.... JIRA fixVersion has its use, and that would satisfy this use-case?  It's what Jan proposes to do this very thing as part of generating release notes in a semi-automated way.

~ David Smiley
Apache Lucene/Solr Search Developer

On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson <> wrote:

> On Jun 3, 2019, at 6:41 AM, David Smiley <> wrote:
> If someone wants to know what branches an issue was committed to, then review the bot comments to find out.

What if I want to form a query that shows me all JIRAs fixed in version X.Y.Z?

A bot comments with “branch_5x” doesn’t tell me which minor version it’s in, 5.1? 5.5?
To unsubscribe, e-mail:
For additional commands, e-mail: