From https://blueprints.launchpad.net/oslo/+spec/oslo-release-versioning

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.

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 ?

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?