On Thursday, 11 June 2020 14:16:34 CEST Jeremy Stanley wrote:
On 2020-06-11 14:05:18 +0200 (+0200), Luigi Toscano wrote: [...]
Can we at least enforce a rule that when tagging the "OpenStack" release, the y number should be increased? Bonus points for having the stabilization (RC) release use y=0, and the stable one starts from y=1.
I know it may not sound to important for a computer, but it's useful for a human eye to know that the first release has a final 0 somewhere? (I really dislike the apache and mysql model in this regard)
As pointed out, this already isn't the case for the many projects currently following this model, especially those which branch earlier in the cycle. It's also a bit of a puzzle... basically every new release you tag on the stable branch could be your final release, so how do you predict in advance that you won't need additional patches?
We are doing time-based release, so we know which is the last version. We know it now (and we call it something.other.0), it would be in the case we moved forward with this exact proposal (but it would be called something.other.somethingelse). Just make sure you bump y too and still use .0 for that specific release. Of course there will be others bugfixes, exactly like we have now. I'm just talking about still retaining a way to more easily identify the first offiical tagged version for a specific coordinated OpenStack release.
I guess you could make every new tag in stable prior to the release a semantic versioning "feature" addition (even though it's really just patch level fixes), so you branch at 14.0.0, and then decide you need some fixes and tag 14.1.0, and then realize you need more fixes so tag 14.2.0, but then after the coordinated release you only increase the patch level of the version to 14.2.1, 14.2.2 and so on. Is that basically what you're suggesting?
You may need to also increase .y after the coordinated release (or so it has happened), so not sure it could be done. But as I said I'm focusing on the 1st release. That said, do projects which tag early needs to increase .y in the time between their first release for a certain cycle and the official first coordinate release? Is the time so long that it may happen? If it's not the case, then I believe that: 14.0.whatever -> during rc time 14.1.0 -> official release 14.y.z, y>=1 rest of lifecycle It means an extra tag if there are no changes between the tagging of 14.0.0 and the tagging of the coodinated release, but I guess that case can be automated. -- Luigi