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)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
