Open Stack

Do we have a list of projects that use alternative release model?
And are these projects follow the same the alternative release model among them?

From: Mark Goddard <mark at stackhpc.com>
Sent: Tuesday, June 9, 2020 3:43 PM
To: Thierry Carrez
Cc: openstack-discuss
Subject: Re: [all][release] One following-cycle release model to bind them all


[EXTERNAL EMAIL]

On Tue, 9 Jun 2020, 11:01 Thierry Carrez, <thierry at openstack.org<mailto:thierry at openstack.org>> wrote:
Hi everyone,

As you know[1] I'm trying to push toward simplification of OpenStack
processes, to make them easier to navigate for new members of our
community and generally remove weight. A good example of that is release
models.

We used to have a single model (with milestones and RCs) but over time
we grew a number of alternative models to accommodate corner cases. The
result is a confusing collection of release models with abstract rules
for each and not much flexibility. Projects are forced to choose between
those models for their deliverables, with limited guidance. And much of
the rationale for those models (exercise release machinery early and
often, trigger external testing...) is no longer valid.

I'd like to suggest we simplify this and have a single model for things
that follow the development cycle: the "follows-cycle" model. The only
alternative, its nemesis, its Wario would be the "independent" release
model.

In the "follows-cycle" model, deliverables would be released at least
once per cycle, but could be released more often. The "final" release
would be marked by creating a release (stable) branch, and that would
need to be done before a deadline. Like today, that deadline depends on
whether that deliverable is a library, a client library, a
release-trailing exception or just a regular part of the common release.

The main change this proposal introduces would be to stop having release
candidates at the end of the cycle. Instead we would produce a release,
which would be a candidate for inclusion in the coordinated OpenStack
release. New releases could be pushed to the release branch to include
late bugfixes or translation updates, until final release date. So
instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted
to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that
14.0.1 in the release page at coordinated release time.

One substantial change here is that there will no longer be a period where the stable branch exists but the coordinated release does not. This could be an issue for cycle trailing projects such as kolla which sometimes get blocked on external (and internal) factors. Currently we are able to revert master from it's temporary stable mode to start development for the next cycle, while we continue stabilising the stable branch for release.

We do intend to be more prompt about our releases, but there is always something that comes up. We may end up having to choose between releasing with known issues vs. halting development for the next cycle. On the other hand, perhaps a little focus would help us to push it over the line faster.


I feel like this would not change that much for deliverables following
the cycle-with-rc model. It would not change anything for
cycle-with-intermediary, libraries or cycle-trailing deliverables. But
it would simplify our processes quite a bit, and generally make our
releases more consistent.

Thoughts?

[1]
http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013236.html

--
Thierry Carrez (ttx)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200609/4cd3ff95/attachment-0001.html>