Open Stack

-----Original Message-----
From: Thomas Goirand <zigo at debian.org>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: January 26, 2016 at 12:48:09
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [all][tc] Stabilization cycles: Elaborating on the idea to move it forward

> On 01/21/2016 02:38 AM, Ian Cordasco wrote:
> > That said, I'd like to see a different release cadence for cycles that are
> > "stabilization cycles". We, as a community, are not using minor version
> > numbers. During a stabilization cycle, I would like to see master be
> > released around the 3 milestones as X.1.0, X.2.0, X.3.0. If we work that
> > way, then we'll be able to avoid having to backport a lot of work to the
> > X.0 series and while we could support X.0 series with specific backports,
> > it would avoid stressing our already small stable teams.
>  
>  
> Hi Ian,
>  
> In which way what you're proposing above is different from what we
> currently have (ie: beta 1, 2 and 3)?

It's different in that these wouldn't be X+1.0.0b{1,2,3} but X.{1,2,3}.0. For a more concrete example, it would be something like:

If Glance were to do this, for mitaka, then instead of releasing 13.0.0b{1,2,3} it would release 12.{1,2,3}.0 at each milestone. According to semantic versioning we could land features in those releases but we'd be communicating more strenuously to consumers that this was really meant to be a release that would be a very very very smooth upgrade experience as it really focuses on stability.

> FYI, even though I often skip the beta 1 (because I'm still working on
> the previous stable), I always release beta 2 and 3 as pre-releases for
> everyone to test. These are uploaded to Debian experimental (well, when
> the next stable Debian isn't frozen...), plus non-official backport
> repositories for stable Debian and Ubuntu. I'd very much welcome more
> people to consume that, but I haven't receive much feedback from it.

Right, I would suspect that this would be because the releases are beta releases and no one wants to spend the time to use/stress them too much. :-/

> > My release
> > strategy, however, may cause more stress for downstream packages
> > though. It'll cause them to have to decide what and when to package
> > and to be far more aware of each project's current development cycle.
> > I'm not sure that's positive.
>  
> I'm not sure why you're saying this (as I probably didn't understand
> your release idea), but what I can tell: don't count on downstream
> distribution to double guess project statuses. It's simply impossible,
> unless we spend a great amount of time communicating with each project,
> which currently can't happen given the current staffing (which I know is
> scarce on all downstream distros, including: Red Hat, Debian, Ubuntu and
> Suse).

Right. I know the downstream teams are small which is why I noted that having a release cadence of actual concrete releases on those milestones instead of beta releases might cause too much work. If it's one service doing that, perhaps not but if several do that in an even remotely synchronized manner, I can imagine that would introduce a lot of work.

Either way, my idea was already shot down because it would mean projects would be changing their release model frequently and that's not desirable.

> Cheers,
>  
> Thomas Goirand (zigo)

--  
Ian Cordasco