Open Stack

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