Open Stack

On 2020-06-11 14:44:19 +0200 (+0200), Luigi Toscano wrote:
[...]
> 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).

How about a concrete example from the last cycle... Horizon. At the
time of the Train coordinated release, the latest version of Horizon
was 16.0.0 (since then Horizon has tagged 16.1.0 and 16.2.0 in their
stable/train branch). In their master branch during the Ussuri
cycle, Horizon made some backward-incompatible changes and tagged
17.0.0, then made feature changes and followed that with 17.1.0,
then made some more backward-incompatible changes and tagged 18.0.0,
then more feature changes for 18.1.0, 18.2.0, 18.3.0... at that
point the end of the cycle was nearing so they branched
stable/ussuri from the 18.3.0 tag, but still had some fixes in
master to backport after that for the coordinated Ussuri release
which resulted in 18.3.1 and 18.3.2 tags. At the time of the Ussuri
coordinated release the latest version of Horizon in stable/ussuri
was 18.3.2 so that's what was announced as part of the coordinated
release.

> Just make sure you bump y too and still use .0 for that specific
> release.

So to be clear, applying your suggestion to the Horizon example
above, after they branched stable/ussuri they should only have done
feature-level semantic versioning increases, tagging 18.4.0 and
18.5.0 instead of 18.3.1 and 18.3.2?

> 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.
[...]

And in your opinion, 18.5.0 looks more official than 18.3.2 as a
part of the coordinated release? Keep in mind that over the course
of the Ussuri cycle, Horizon tagged no fewer than 6 new versions
ending in .0 so are you similarly concerned that those might look
"too official" when they were just marking points in master branch
development?

> 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.

Yes, projects who are concerned with doing that (remember that those
following stable branch policy should *not* merge changes which
would require a feature level semantic version increase in their
stable branches) can artificially increase the first version
component in master to make sure it will always be greater than any
feature bumps in latest stable.

> 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.

It already is automated with the re-tagging of the latest rcN
version to some release version in cycle-with-rc projects today, and
this re-tagging dance is a big part of what we're hoping to do away
with to simplify the release process. If it really is important that
the coordinated release versions have a .0 on the end of them, then
I'd rather just have a policy that all subsequent versions tagged in
stable branches before release day must be feature level semantic
version increases rather than patch level. At least then nothing
needs to be re-tagged.

Granted, I find this slightly obsessive, and don't understand what's
wrong with the many, many versions we include in our coordinated
releases already which don't end in a .0 patch level. It also makes
it harder to identify actual feature changes in libraries which need
requirements freeze exceptions, and so will likely mean a lot more
work on the requirements team to figure out if a new lib version is
actually safe at that time (bug fixes masquerading as a feature
increase). Your alternative, re-tagging them, means additional churn
in requirements as well, at a rather disruptive time in the release
cycle.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200611/2dfcebd2/attachment.sig>