Since it’s still a bit blurry on some aspects, I would like us to decide a simple and consistent set of rules on how we deal with versions in pom, issues and release notes.
Currently, the rule for the previous version in the pom is explicitly written: the previous version of 17.3.0RC1 is 17.2.2.
It’s not so explicit for the release note and the Fix Version/s jira issues, and the result is that you find various rules applied.
I propose to keep following the written rule we have for the pom and apply the following for other aspects:
the previous version indicated in the RN (New and Noteworthy, API Breakages) should be the same as the one in the pom
when closing an issue, don’t try to be clever and just set the next version for each branch on which the issue was committed (it’s not always easy to know when, or even if, a bugfix release will be released). So for example, when closing Loading..., set both 17.3.0-rc-1 and 17.2.2.
but then the release manager (so we need to add an entry in the release plan) should make sure to remove from jira issues the released version if the issue was also fixed in the previous version (or a lower version). For the previous example, it means that @surli should remove 17.3.0-rc-1 from Loading... and Loading... when releasing 17.3.0RC1.
I’m clearly +1 on that, it happened a lot to me in the past to use that rule personally and then have to change the fix versions especially in LTS branches before a .0.0.
I guess we might need some automated way for that because it can be easily tedious when releasing X.0.0.
I’m wondering if we shouldn’t add this previous version in the RN object directly so that we reuse the value everywhere without having to think about it.
Globally +1 on the idea to simplify for having something more consistent.
I’m not sure about this. When you look at a JIRA issue, and you see “Fix Versions: 17.2.2” how do you know that it was also fixed in 17.3.0RC1? You’d have to check if 17.3.0RC1 was released after 17.2.2, but even in that case, how do you know the fix was cherry-picked? You’d have to check. I feel this makes it harder to find out in which versions a JIRA issue was fixed. I’m used to seeing:
either a non-bugfix version (e.g. 17.3.0RC1 or 17.3.0) followed by zero or more bugfix versions where the fix was cherry-picked (e.g. 17.2.2)
or a single bugfix version, in case the fix was introduced in a bugfix version (e.g. doesn’t affect master)
Note that it’s exactly what is currently happening when we’re fixing X.10.1/2: we’re not supposed to indicate the new 0.0RC1 in the fix version, and yet we do push in master.
LTS (X.10.1/2) is an exception for me. Initially we had two more major versions (e.g. 16.11 and 16.12) but we made them bugfix releases of X.10 (i.e. 16.10.1 and 16.10.2). When I see X.10.1/2 I understand what it means. I can’t say the same about 17.2.2.
So you suggest we keep all versions where it’s fixed? Basically the version would match exactly the branches where we pushed the fix.
The only problem I see in this case is that we would see in both Release notes of 17.2.2 and 17.3.0RC1 the same issues fixed.
The advantage is that it’s easier to handle and even more clear when looking at the tickets.
For me the main problem for doing that is in case of LTS: we would see a lot of tickets fixed in X.0.0 while they were fixed in LTS, and I believe we should have same rules for LTS and other minor bug fixes to simplify.
I think it’s important for a ticket to state clearly in which versions it was fixed (cherry-picked).
Indeed, but is this a new problem? We have been using the X.10.1/2 LTS versioning scheme for some years now. Can’t we tweak the JIRA query for these two specific versions?
You are only focusing on a single aspect here, and the point of this whole thread is to stop doing that because it leads to inconsistent release notes, which is a very bad idea IMO.
So what do you propose to avoid this problem ?
I hesitated to list several proposals initially, but since we already had a written rule for the pom, I decided to propose only one, based on it. But here are more choices I can think of:
The proposal at the beginning of this thread
The proposal at the beginning of this thread, but with the following variations:
No version removed from the jira issues at release time
Always compare x.y.0 to x.y-1.0 (instead of x.y-1.<current>). Which means the 17.3.0 release note, pom and dashboard are comparisons with 17.2.0, and not 17.2.2. But then it feels strange to compare x.0.0 to x-1.10.0, so what should we do:
3.a. No, it’s fine.
3.b. Compare x.0.0 to x-1.10.2. This is easy for the pom and the release note, but for jira we need to choose between several possibilities:
3.b.1. Like we usually did so far, x.0.0 is not set in the Fix Version/s of any jira issue which is also cherry-picked in x-1.10.1 or x-1.10.2.
3.b.2. Contrary to the current practice, the jira issues contain all versions, but we filter out x-1.10.1 and x-1.10.2 in the query of the x.0.0 dashboard.
My vote goes to 2. since it seems to be the simplest to implement and understand, while covering the concerns expressed so far.
Thank you, Thomas, for listing all the options. If everyone else is OK with 1 I won’t oppose it. I just wanted to raise a concern because I rely on the Fix Version to quickly find out which versions (branches) have the fix.