Open Stack

On Thu, 2012-11-22 at 23:21 -0800, Monty Taylor wrote:
> 
> On 11/22/2012 09:44 AM, Mark McLoughlin wrote:
> > Well, to add two more questions:
> >
> >    * When do we commit to compatibility around a new API in Oslo? When
> >      it gets committed, when it gets released or when we release an
> >      officially "API frozen" version?
> 
> I vote for when it gets released.
> 
> >    * How do other OpenStack projects consume Oslo libraries during
> >      development? e.g. can you put a git URL into pip-requires, or must
> >      you have a pypi release version there?
> >
> > You could say e.g. new APIs are committed to when they're released to
> > pypi and OpenStack projects can only consume new APIs once they've been
> > released to pypi.
> 
> Yes please. We have done cross-project git-url consumption before. It's 
> a nightmare (largely because although the python toolchain tempts us 
> into thinking this will work, it doesn't actually fully work.
> 
> > But that could result us doing library releases too often, integration
> > with other projects being too slow or us only realizing we've made
> > drastic API design mistakes after committing to the new API.
> 
> Honestly, I think you have a slightly easier time of it than the client 
> lib folks in terms of API commitment - since you know who your consumers 
> are, and you can actually check around to see if anyone is using an old 
> API. It's not too terrible - how about we try it that way for a bit and 
> see if there are actual logistical problems?

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 :-)

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.

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

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.

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.

Cheers,
Mark.