<br><br><div class="gmail_quote">On Tue, Nov 13, 2012 at 9:19 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>From <a href="https://blueprints.launchpad.net/oslo/+spec/oslo-release-versioning" target="_blank">https://blueprints.launchpad.net/oslo/+spec/oslo-release-versioning</a><br>
<br>
> Before we can release Oslo's first library package, we must agree on a versioning scheme.<br>
><br>
> 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.<br>
<br>
A bit of explanation there. The core projects (except Swift) follow a<br>
common development cycle and versioning scheme that culminates with the<br>
common release, every 6 months. That supports pre-versioning (milestones<br>
as alphas and betas leading towards the final release) and<br>
post-versioning (point releases updates on stable releases). We don't<br>
release those to PyPI, we release those on Launchpad, which has a rather<br>
neat "series" concept that makes it clear what is a a preversion and<br>
what is a postversion.<br>
<br>
For client libraries, we used to follow that common model. But there was<br>
a need to push versions up on PyPI so that they could be used asap. The<br>
first issue with PyPI is its extremely-limited preversioning support: it<br>
could not match our milestones (the 2013.1~g1 stuff). The other issue is<br>
that PyPI only considers a single "version channel": 2.0b1 is seen as an<br>
update to 1.2.1 (it could be thought of as only showing one series for a<br>
given module).<br>
<br>
For client libraries, we decided that they would not follow the common<br>
release at all and do ad-hoc versioning (making the preversioning issue<br>
go away) and that they would use a single version channel (no stable/*<br>
branches for client libraries, the last version is always supposed to<br>
support older APIs), so the single version channel was not an issue<br>
either. That made the PyPI solution totally adequate for them. I'm just<br>
not sure we can assume the same for oslo libraries.<br>
<br>
> 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?<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Adding another question: should all oslo libraries share the same<br>
versioning ? i.e. should oslo.config version be updated when oslo.rpc<br>
needs to be released ?<br></blockquote><div><br></div><div>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.).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Which versions get released to PyPi? Should we have a stable branch of these libraries with stable releases?<br>
<br>
That's the crux of the issue. We have two valid models:<br>
<br>
1- Integrated with common release, using common versioning, not using<br>
PyPI, supporting stable/* branches and stable point releases<br>
<br>
2- Ad-hoc versioning, ignoring the common cycle, using PyPI (which makes<br>
stable point releases look weird)<br>
<br>
I'm not sure there is a middle solution. I guess we /could/ support<br>
stable branches and stable point releases in solution (2), despite<br>
PyPI's lack of good support for it... but then I'd prefer if those<br>
stable branches were disconnected from the common release cycle (i.e.<br>
the stable series would be "1.x" and not "folsom") so that we don't tie<br>
a lot of different weird version numbers to a given series.<br>
<br>
Thoughts?<br></blockquote><div><br></div><div>We could also approach the PyPI maintainers about improving support for multiple release channels for a given project.</div><div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<span class="HOEnZb"><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
Release Manager, OpenStack<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br>