Open Stack

On Tue, 2012-11-13 at 15:19 +0100, Thierry Carrez wrote:
> From https://blueprints.launchpad.net/oslo/+spec/oslo-release-versioning
> 
> > Before we can release Oslo's first library package, we must agree on a versioning scheme.
> > 
> > The core services projects follow one versioning scheme and the client libraries follow another scheme, but this is our first time releasing a library which supports the core services.
> 
> A bit of explanation there.

(snip good summary, agree we can't assume same solution as client
libraries works here)

> > Should Oslo library packages be part of the co-ordinated release schedule along with the core services? Or should they follow their own (ad-hoc?) release schedule?
> 
> Adding another question: should all oslo libraries share the same
> versioning ? i.e. should oslo.config version be updated when oslo.rpc
> needs to be released ?

No, it's not required, but I think there's some value in a checkpoint
release of all the libraries in the same family using the same version.
It would just make it easier for folks to understand which versions
belong together, given they will be dependent on each other.

> > Which versions get released to PyPi? Should we have a stable branch of these libraries with stable releases?
> 
> That's the crux of the issue. We have two valid models:
> 
> 1- Integrated with common release, using common versioning, not using
> PyPI, supporting stable/* branches and stable point releases
> 
> 2- Ad-hoc versioning, ignoring the common cycle, using PyPI (which makes
> stable point releases look weird)
> 
> I'm not sure there is a middle solution. I guess we /could/ support
> stable branches and stable point releases in solution (2), despite
> PyPI's lack of good support for it... but then I'd prefer if those
> stable branches were disconnected from the common release cycle (i.e.
> the stable series would be "1.x" and not "folsom") so that we don't tie
> a lot of different weird version numbers to a given series.

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?

  * 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.

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.

Hmm.

Mark.