Open Stack

I think we should continue with option 1.

It is an indicator that a project is active in OpenStack and is
explicit about which code should be used together.

Both of those statements hold no technical water, but address the
"human" factor of "What is OpenStack?", "What do I need to deploy?",
"What is an active project and what is not?", and "How do we advertise
what OpenStack can provide?".

I think 2 and 3 will just lead to confusion and frustration for folks.

Michael
On Mon, Jun 11, 2018 at 7:50 AM Doug Hellmann <doug at doughellmann.com> wrote:
>
> Excerpts from Thierry Carrez's message of 2018-06-11 11:53:52 +0200:
> > 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
>
> Although I originally considered it separate, reviewing your summary
> I suspect option 2bis is most likely to turn into option 3, in
> practice.
>
> I think having the choice between options 2 and switching to an
> independent release model (maybe only for libraries) is going to
> be best, at least to start out.
>
> Stein will be the first series where we have to actually deal with
> this, so we can see how it goes and discuss alternatives if we run
> into issues.
>
> Doug
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev