Open Stack

On Tue, Nov 13, 2012 at 9:19 AM, Thierry Carrez <thierry at openstack.org>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. 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?
>

Giving them their own release schedule solves the pre-versioning problem
because we can release a stable version with its actual version number to
PyPI in the middle of the synchronized release cycle followed by the other
projects.


>
> 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, they should be versioned separately using the same sort of versioning
followed by other libraries (simple major.minor.patch numbering, API
compatibility within major.minor versions, etc.).


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

We could also approach the PyPI maintainers about improving support for
multiple release channels for a given project.

Doug


>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121113/4e1a35dc/attachment.html>