Re: [release] (a bit belated) Release countdown for week R-11, July 29 - August 2
The release management team discussed this topic at the meeting yesterday.
The current process works well in the case where you *know" you will
only do one release (release-once), or you *know* you will do more than
one release (release-often). We agree that it does not handle well the
case where you actually have no idea how many releases you will do
We need to add a bit of flexibility there, but:
- the release team still needs to use a very limited number of standard
release models, and know as much as possible in advance. We handle
hundreds of OpenStack deliverables, we can't have everyone use their own
- we don't want to disconnect project teams from their releases (we
still want teams to trigger release points and feel responsible for the
Here is the proposal we came up with:
- The general idea is, by milestone-2, you should have picked your
release model. If you plan to release-once, you should use the
cycle-with-rcs model. If you plan to release-often, you should be
cycle-with-intermediary. In the hopefully rare case where you have no
idea and would like to release-if-needed, continue to read.
- Between milestone-2 and milestone-3, we look up
cycle-with-intermediary things that have not done a release yet. For
those, we propose a switch to cycle-with-rcs, and use that to start a
At that point four things can happen:
(1) you realize you could do an intermediary release, and do one now.
Patch to change release model is abandoned.
(2) you realize you only want to do one release this cycle, and +1 the
(3) you still have no idea where you're going for this deliverable this
cycle and would like to release as-needed: you -1 the patch. You
obviously commit to producing a release before RC1 freeze. If by RC1
freeze we still have no release, we'll force one.
(4) you realize that the deliverable should be abandoned, or should be
disconnected from the "OpenStack" release and be made independent, or
some other solution. You -1 the patch and propose an alternative.
In all cases that initial patch is the occasion to raise the discussion
and cover that blind spot, well in advance of the final weeks of the
release where we don't have time to handle differently each of our
hundreds of deliverables.
Dmitry Tantsur wrote:
> Have you considered allowing intermediary releases with cycle-with-rc?
> Essentially combining the two models into one?
You really only have two different scenarios.
A- the final release is more usable and important than the others
B- the final release is just another release, just happens to have a
stable branch cut from it
In scenario (A), you use RCs to apply more care and make sure the one
and only release works well. You can totally do other "releases" during
the cycle, but since those are not using RCs and are not as carefully
vetted, they use "beta" numbering.
In scenario (B), all releases are equally important and usable. There is
no reason to use RCs for one and not the others.
Thierry Carrez (ttx)