Excerpts from Michael Johnson's message of 2018-06-12 08:41:57 -0700: > 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 don't expect for oslo.i18n to see any patches during Stein, but it is still maintained. Is it still part of OpenStack under this definition? > > 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 <d...@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-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev