atom feed31 messages in org.openstack.lists.openstack-dev[openstack-dev] [oslo] Oslo library v...
FromSent OnAttachments
Thierry CarrezNov 13, 2012 6:19 am 
Doug HellmannNov 13, 2012 9:12 am 
Mark McLoughlinNov 22, 2012 9:44 am 
Monty TaylorNov 22, 2012 11:21 pm 
Thierry CarrezNov 23, 2012 2:54 am 
Doug HellmannNov 26, 2012 6:38 am 
Monty TaylorNov 26, 2012 7:20 am 
Matt JoyceNov 26, 2012 12:06 pm 
Monty TaylorNov 26, 2012 12:30 pm 
Mark McLoughlinNov 26, 2012 2:33 pm 
Mark McLoughlinNov 26, 2012 2:40 pm 
Thierry CarrezNov 27, 2012 5:31 am 
Adam YoungNov 27, 2012 6:39 am 
Monty TaylorNov 27, 2012 8:21 am 
Mark McLoughlinNov 27, 2012 8:45 am 
Joshua HarlowNov 27, 2012 10:11 am 
Mark McLoughlinNov 30, 2012 5:45 am 
Joshua HarlowNov 30, 2012 11:07 am 
Monty TaylorNov 30, 2012 11:26 am 
Monty TaylorNov 30, 2012 11:29 am 
Matt JoyceNov 30, 2012 1:24 pm 
Monty TaylorNov 30, 2012 1:55 pm 
Joshua HarlowNov 30, 2012 2:12 pm 
Monty TaylorNov 30, 2012 2:24 pm 
Mark WashenbergerDec 2, 2012 8:49 pm 
Thierry CarrezDec 3, 2012 2:09 am 
Mark McLoughlinDec 3, 2012 3:23 am 
Mark McLoughlinDec 3, 2012 3:32 am 
Monty TaylorDec 3, 2012 11:20 am 
Monty TaylorDec 3, 2012 11:36 am 
Monty TaylorDec 3, 2012 11:38 am 
Subject:[openstack-dev] [oslo] Oslo library versioning
From:Thierry Carrez (
Date:Nov 13, 2012 6:19:42 am


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

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.