Open Stack

Mark McLoughlin wrote:
> That actually goes to something I'm not aware of us - the project -
> having spent much time discussing. We do twice yearly releases of our
> collection of software, but there are public cloud providers which want
> to essentially do continuous deployment from our development branch.
> 
> To what extent is that a reasonable thing for the project to support? If
> we had a shorter release cycle, would the cloud providers switch their
> deployments from continuous to the releases? If not, can the project and
> cloud providers better co-ordinate somehow?

That's a discussion we had before the Essex release, when we were
looking into releasing more often (every 5-8 weeks) instead of every 6
months. "What makes a release ?". After all, you will never prevent
people from using milestones or random snapshots, and we should strive
to make master always installable and working. So why do releases ? And
what should be the cadence ?

To me, releases are synchronization points. We have to have a cycle with
a timeframe where development slows down at one point to let QA,
documentation, integration testing and translation catch-up. A release
is a point in time where the stars are all aligned. The release cycle is
there to help us achieve that regularly.

Those synchronization points also serve to maintain stable branches and
coordinate with distros (it's no mystery that we are cadenced in a way
that makes us friendly with time-based distros).

Currently we can only achieve that star-aligning process every 6 months,
but I hope that we'll be able to do releases more often in the future.

That said, us releasing every 6 months doesn't mean we should prevent
users from being able to pick a version and run with it. In particular,
I think our client library release scheme shouldn't actively go against
that by synchronizing too much with the core release schedule.

> [...]
> For argument sake, and given a 6 month cycle, say that's 2 months before
> the release date. For Folsom, that's the folsom-3 milestone.
> 
> Before that date, the project recommends that public cloud providers
> deploying Folsom from our development branch does not expose any of the
> new REST APIs which were added in Folsom. Assume we have provided a
> mechanism (e.g. a config option) to make that possible.
> 
> That means that we don't need a release of client libs with support for
> those APIs until folsom-3.

Even in this constraining setup, you keep the user vs. developer
dichotomy: you want developers and early testers to actually play with
your new REST APIs... so you still need two "channels": "developer" and
"supported".

I think Monty's solution is a way to support both in the same channel,
as everyone wants to use PyPI and it supports only a single channel.

My understanding is that you resist it because you think it will break
during the development cycle, so releasing only when APIs to be "ready
and official" is safer. What about mandating that "new REST APIs" get
exposed in the client using a "experimental" or "non-final-yet" flag ?
And when they get official (folsom-3 ?) we expose them to all users ?

Then you could have both stable and experimental APIs live happily
together... in the same PyPI channel and in the same stream of releases.

> [...]
> e.g. I could see us doing this:
> 
>   - When we hit essex-3, we did the first release of the client libs 
>     which supported new REST APIs added in Essex
> 
>   - We continue adding bugfixes and new client lib features based on the
>     essex APIs to the master branch of the client project
> 
>   - At Essex release time, we do another release of the client libs ... 
>     purely to co-ordinate with the project release
> 
>   - We continue doing releases as the need arises
> 
>   - At some point, new REST APIs are added in Folsom and we want the 
>     client lib to support it. At that point, we branch off an 'essex' 
>     branch of the lib. Support for those new REST APIs goes into 
>     master, everything else goes into both.
> 
>   - We continue doing releases from the essex branch

Alternatively, the new API could be developed in a "next" branch and
merged in around folsom-3. I think that would be more consistent with
how we do things, and you don't have to switch branches you release from.

>   - When we hit folsom-3, the REST APIs freeze and we do our first
>     release containing support for the new REST APIs added in Folsom

The trick here is that your new REST APIs only get exposed in a
published version of the client library at folsom-3, which is quite
late. That would work if only end users consumed the library, and all
end users would run on final releases. But our projects also use the
libs to communicate between themselves. If API changes all land in F3,
when does Horizon work to integrate the new featureset ? They actually
need to work with experimental APIs available in the client libs as
early as possible to integrate the new featureset in time for final
release...

So I think I still prefer the single branch model, although I'd like it
to be protected with some "experimental" mode to limit the risk on end
users of the latest stable release.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack