|Thierry Carrez||Nov 13, 2012 6:19 am|
|Thierry Carrez||Nov 23, 2012 2:54 am|
|Doug Hellmann||Nov 26, 2012 6:37 am|
|Matt Joyce||Nov 26, 2012 12:06 pm|
|Monty Taylor||Nov 26, 2012 12:29 pm|
|Mark McLoughlin||Nov 26, 2012 2:32 pm|
|Adam Young||Nov 27, 2012 6:39 am|
|Mark McLoughlin||Nov 27, 2012 8:45 am|
|Joshua Harlow||Nov 27, 2012 10:10 am|
|Joshua Harlow||Nov 30, 2012 11:07 am|
|Monty Taylor||Nov 30, 2012 11:28 am|
|Matt Joyce||Nov 30, 2012 1:24 pm|
|Monty Taylor||Nov 30, 2012 1:55 pm|
|Joshua Harlow||Nov 30, 2012 2:12 pm|
|Mark Washenberger||Dec 2, 2012 8:49 pm|
|Thierry Carrez||Dec 3, 2012 2:08 am|
|Mark McLoughlin||Dec 3, 2012 3:22 am|
|Mark McLoughlin||Dec 3, 2012 3:32 am|
|Monty Taylor||Dec 3, 2012 11:36 am|
|Monty Taylor||Dec 3, 2012 11:37 am|
|Subject:||[openstack-dev] [oslo] Oslo library versioning|
|From:||Thierry Carrez (thie...@openstack.org)|
|Date:||Nov 13, 2012 6:19:19 am|
Before we can release Oslo's first library package, we must agree on a
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.
-- Thierry Carrez (ttx) Release Manager, OpenStack
_______________________________________________ OpenStack-dev mailing list Open...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev