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.