[openstack-dev] [all] Switching to longer development cycles

Clint Byrum clint at fewbar.com
Thu Dec 14 06:36:39 UTC 2017


Excerpts from Ed Leafe's message of 2017-12-13 22:51:19 -0600:
> On Dec 13, 2017, at 4:31 PM, Doug Hellmann <doug at doughellmann.com> wrote:
> 
> > You're missing the key point that coupled with the change in the
> > overall development cycle schedule we would be encouraging projects
> > to release more often.  I'd personally rather do away with milestones
> > altogether and just tag everything monthly, but some projects may
> > not be ready to do that and some may want to go more often (libraries
> > in particular).
> 
> I think you're missing the reality that intermediate releases have about zero uptake in the real world. We have had milestone releases of Nova for years, but I challenge you to find me one non-trivial deployment that uses one of them. To my knowledge, based on user surveys, it is only the major 6-month named releases that are deployed, and even then, some time after their release.
> 
> Integrated releases make sense for deployers. What does it mean if Nova has some new stuff, but it requires a new release from Cinder in order to use it, and Cinder hasn't yet released the necessary updates? Talking about releasing projects on a monthly-tagged basis just dumps the problem of determining what works with the rest of the codebase onto the deployers.
> 
> 

This isn't really fair to the users. They're running what we tell them
to run. They're also running what we try to test together, which is all
the same versions of the same components at integrated release time.

While I do think most users _should_ stick to what's tested together,
and we should keep testing things together, I also think we should be
more comfortable telling users to go ahead and install a new release of
Nova and feel confident they're going to be supported in doing so.

The batch size for "upgrade the whole cloud" is too big. Let's help our
users advance components one at a time, and then we won't have to worry
so much about doing the whole integrated release dance so often.



More information about the OpenStack-dev mailing list