modify the filter to set the right including and excluding versions: fixVersion in (17.5.0-rc-1, 17.5.0) AND fixVersion not in (17.4.1) a RC or first stable version, or just fixVersion in (17.5.1) for a bugfix version
When closing a Solved or Fixed jira issue, the next version of each branch where the issue was applied should be added to “Fix Version/s”. For example if you commit an issue in master, and stable-17.4.x with the respective next versions being 17.5.0-rc-1 and 17.4.1, you should indicate both versions.
But, following the rule strictly, bugfixes done between the final and the RC must have two versions, the final version and the next RC (since they are commited on each branch).
For instance, if 18.0.0RC1 is just released, a bugfix for 18.0.0 will be commited on master and stable-18.0.x.
Therefore, the issue is expected to have fix versions 18.0.0 and 18.1.0-rc-1.
The filters for the RN dashboards will be
for 18.0.0-rc-1/18.0.0: fixVersion in (18.0.0-rc-1, 18.0.0) AND fixVersion not in (17.10.1, 17.10.2) (assuming both fix releases are excluded for EOY) (so the issue is included)
for 18.1.0-rc-1/18.1.0: fixVersion in (18.1.0-rc-1, 18.1.0) AND fixVersion not in (18.0.1) (so the issue is included again since 18.0.0 is not excluded).
So first I’d like to validate the fact that the issue appearing in two release notes is the expected behavior.
And if not, I propose to:
make it clear that issues for final releases don’t follow the same rule
provide additional examples in the documentation to make it easier to understand
So here we have 2 choices: either we follow strictly the rule as you described it (proposition 1), or we decide that for tickets happening between RC and final we only specify the final version, not the next RC (proposition 2).
So in your example the ticket would only have 18.0.0 as fix version. Advantage of this proposition is that it prevents appearing in the 2 RN and I think it’s what we used to do, and probably what we’re still doing in practice.
The only disadvantage I see is that it goes against:
don’t try to be clever and just set the next version for each branch on which the issue was committed
of the first proposal. So we need to be a bit more careful on those, but since it’s already what we did in the past…
So I’d be +1 for proposition 2, now I’m -0 for proposition 1.
+1. Issues fixed in 18.0.0, after 18.0.0-rc-1, shouldn’t have 18.1.0-rc-1 as fix version, because 18.1.0-rc-1 is always after 18.0.0, and everything we put in 18.0.0 should be in 18.1.0-rc-1 as well.
Sorry, as I did not make propositions in my initial post, I’m not sure I understand what you are voting for.
It’s probably because something is not clear in my post
The previous proposal was actually very focused on bugfix releases of the previous branch. It indeed does not make much sense to indicate both 18.0.0 and 18.1.0-rc-1 just because we move 18.0.x in its own branch before the final release. It’s actually worst than what you described by the way since we may close some issue between the time we create the branch and the time we release the RC1 with the new rule to create the branch half a week before releasing the RC1.
So +1 to keep doing what we always did and treat first final (and RC) version of a branch as being special.
