Open Stack

>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. The core projects (except Swift) follow a
common development cycle and versioning scheme that culminates with the
common release, every 6 months. That supports pre-versioning (milestones
as alphas and betas leading towards the final release) and
post-versioning (point releases updates on stable releases). We don't
release those to PyPI, we release those on Launchpad, which has a rather
neat "series" concept that makes it clear what is a a preversion and
what is a postversion.

For client libraries, we used to follow that common model. But there was
a need to push versions up on PyPI so that they could be used asap. The
first issue with PyPI is its extremely-limited preversioning support: it
could not match our milestones (the 2013.1~g1 stuff). The other issue is
that PyPI only considers a single "version channel": 2.0b1 is seen as an
update to 1.2.1 (it could be thought of as only showing one series for a
given module).

For client libraries, we decided that they would not follow the common
release at all and do ad-hoc versioning (making the preversioning issue
go away) and that they would use a single version channel (no stable/*
branches for client libraries, the last version is always supposed to
support older APIs), so the single version channel was not an issue
either. That made the PyPI solution totally adequate for them. I'm just
not sure we can assume the same for oslo libraries.

> 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 ?

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

Thoughts?

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack