Open Stack

Hi everyone,

As some of the OpenStack deliverables get more mature, we need to adjust 
our release policies to best handle the case of deliverables that do not 
need to be updated that much. This discussion started with how to handle 
those "stable" libraries, but is actually also relevant for "stable" 
services.

Our current models include cycle-tied models (with-intermediary, 
with-milestones, trailing) and a purely cycle-independent model. Main 
OpenStack deliverables (the service components that you can deploy to 
build an OpenStack cloud) are all "released" on a cycle. Libraries are 
typically maintained per-cycle as well. What happens if no change is 
pushed to a service or library during a full cycle ? What should we do 
then ?

Options include:

1/ Force artificial releases, even if there are no changes

This is the current state. It allows to reuse the exact same process, 
but creates useless churn and version number confusion.

2/ Do not force releases, but still create branches from latest releases

In this variant we would not force an artificial re-release, but we 
would still create a branch from the last available release, in order to 
be able to land future patches and do bugfix or security releases as needed.

2bis/ Like 2, but only create the branch when needed

Same as the previous one, except that rather than proactively create the 
stable branch around release time, we'd wait until the branch is 
actually needed to create it.

3/ Do not force releases, and reuse stable branches from cycle to cycle

In this model, if there is no change in a library in Rocky, stable/rocky 
would never be created, and stable/queens would be used instead. Only 
one branch would get maintained for the 2 cycles. While this reduces the 
churn, it's a bit complex to wrap your head around the consequences, and 
measure how confusing this could be in practice...

4/ Stop worrying about stable branches at all for those "stable" things

The idea here would be to stop doing stable branches for those things 
that do not release that much anymore. This could be done by switching 
them to the "independent" release model, or to a newly-created model. 
While good for "finished" deliverables, this option could create issues 
for things that are inactive for a couple cycles and then pick up 
activity again -- switching back to being cycle-tied would likely be 
confusing.


My current preference is option 2.

It's a good trade-off which reduces churn while keeping a compatibility 
with the system used for more active components. Compared to 2bis, it's 
a bit more work (although done in one patch during the release process), 
but creating the branches in advance means they are ready to be used 
when someone wants to backport something there, likely reducing process 
pain.

One caveat with this model is that we need to be careful with version 
numbers. Imagine a library that did a 1.18.0 release for queens (which 
stable/queens is created from). Nothing happens in Rocky, so we create 
stable/rocky from the same 1.18.0 release. Same in Stein, so we create 
stable/stein from the same 1.18.0 release. During the Telluride[1] cycle 
some patches land and we want to release that. In order to leave room 
for rocky and stein point releases, we need to skip 1.18.1 and 1.19.0, 
and go directly to 1.20.0. I think we can build release checks to ensure 
that, but that's something to keep in mind.

Thoughts ?

[1] It's never too early to campaign for your favorite T name

-- 
Thierry Carrez (ttx)