Open Stack

On 2020-06-10 17:15:46 +0200 (+0200), Thomas Goirand wrote:
[...]
> I don't buy into the "this is only cosmetic": that's not what's
> going to happen, unfortunately. Obviously, in your example, 14.0.0
> will *NOT* be considered a pre-release of the next stable. 14.0.0
> will be seen as the "final release" version, ie: the first stable
> version.

That's no different from how it works now, other than the actual
characters in the version string. Currently most projects cut a
stable/whatever branch from an rc1 tag and then the same commit
which got that rc1 tag gets re-tagged with the release version tag.
In Thierry's proposal we'd just use an actual release-numbered tag
rather than an rc1 tag. Projects which previously got an rc2 in
their stable branch before the official coordinated release date
would do a .1 point release there instead.

> This means that we wont have tags for the pre-release.

We will, they'll just have release-like numbers on them (but the
third component of the release number may not be the same if a patch
version is tagged in that stable branch prior to the coordinated
release). In Thierry's example, 14.0.0 is a candidate for the
coordinated release just like 14.0.0.0rc1 would have been, but if
issues are found with it then there could be a 14.0.0.1 before the
coordinated release date, similar to 14.0.0.0rc2. The same factors
which drive some projects to need a second (or third, or fourth)
release candidate would still be present to cause them to want a
second (or third, or fourth) patch version before the coordinated
release date.

> If the issue is just cosmetic as you say, then let's keep rc1 as
> the name for the pre-release version.

The workflow difference is primarily cosmetic (other than not
necessarily needing to re-tag the last release candidate at
coordinated release time). The issue it solves is not cosmetic: we
currently have two primary release models, one for services and
another for libraries. This would result in following the same model
for services as we've been using to release libraries for years,
just at a different point in the cycle than when libraries are
released.
-- 
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/20200610/e4fd2f69/attachment.sig>