Open Stack

Mark McLoughlin wrote:
> Leaving aside mechanics for a second, the more I think about this the
> more I'm coming to a pretty firm view ...
> 
> I want the 6 month release cycle model for Oslo. I want the project to
> go through a bunch of hacking for the first part of that cycle and lock
> things down towards the end of the release. I want Oslo to have a stable
> branch where people can get fixes without the risk of new features. I
> want milestone release checkpoints to focus the mind and not have one
> long period of hacking before a release. I want Oslo's cycle to be in
> sync with the projects which are using Oslo's APIs. I want people to
> intuitively understand what Oslo's cycle is rather than it having a
> bunch of special rules. And I want Thierry's help coordinating all
> this :-)

Note that you can have most of these benefits without adopting the
common "core" milestone/release cycle. In particular, you can have
stable branches, and follow a rhythm that is inspired by the release
cycle. That said, I agree with you that you can't have the intuitive
understanding or the clear milestone checkpoints unless you follow the
core release cycle. And I won't be the one discouraging anyone of
following it. I just want the benefits and drawbacks to be clearly
understood :)

For example, following your pretty firm view you would end up
potentially releasing major versions of a library that do not include
any significant change (2014.1 being roughly the same as 2013.2). I
expect libraries to become pretty stable at some point, so separate
versioning kind of made sense to me: there aren't so many ways we can
refactor oslo-config left, so at some point all projects should be happy
to consume oslo-config 1.2.x forever.

> Basically, my instinct is to do everything just like any of the other
> core projects except in those cases where Oslo really is a special case.
> 
> The main difference is other core projects are consuming APIs provided
> by Oslo.

We end up with exactly the same issue we ran into with client libraries.
Those needed to "be released" so that they would be consumed by
development versions of the core projects, and the solution was to have
them under their own schedule. I was not a big fan of the resulting
confusion, but I couldn't see any other solution.

> I think it makes sense to say other projects can only consume new Oslo
> APIs if they've actually been released.

Right, one way to solve the issue is to make H consume the G stable
branch. Or to release Oslo/G a bit before the rest of G so that final G
can consume G oslo libraries. But in both solutions that limits the
benefit of following the common cycle (since you end up not following
the same cycle and checkpoints).

> I wouldn't like to see Oslo development releases go on pypi. To me, that
> would give those releases an inaccurate appearance of stability. I would
> like to see stable branch releases going to pypi.

That would solve the pre-release versioning support problem (the fact
that PyPI has very basic support for preversions, nothing like what we
use in the common release cycle currently). But my understanding was
that PyPI was pretty central to our library consumption model.

> During development, I think we should have some wiggle room to fix up
> bad API design errors even after we've done a development release with
> those errors. If we can notice the error, add a better API, deprecate
> the broken API, update all the core projects and remove the broken API
> before final release, I think that's workable.
> 
> Can we figure out the mechanics to make this all possible? e.g. can we
> push tarball releases somewhere during development other than PyPi and
> just reference those tarball URLs directly in pip-requires? At release
> time, we'd push Oslo releases to PyPi and update the core projects to
> use those as their dependencies rather than URLs.

Maybe Monty has a wildcard up his sleeve...

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack