[openstack-dev] [oslo] versioning and releases

Robert Collins robertc at robertcollins.net
Tue Jun 17 22:42:29 UTC 2014


On 11 June 2014 04:24, Doug Hellmann <doug.hellmann at dreamhost.com> wrote:
...
> Incubated libraries have been released at the end of a release cycle,
> as with the rest of the integrated packages. Adopted libraries have
> historically been released "as needed" during their development. We
> would like to synchronize these so that all oslo libraries are
> officially released with the rest of the software created by OpenStack
> developers.

So I see a fairly big problem with this - its going to impact heavily
on anyone that isn't part of oslo using oslo.* as a library. For
instance, the openstack clients which use oslo.config - they will not
be able to get new features or bugfixes from trunk without waiting 6
months. And that means either:
 - carrying conditional code (version checking the version of oslo) in
their trunk,
 - or not consuming new features until up to 6 months after release
 - or making their trunk *uninstallable* (because it will have either
an dep on a non-existing version, or a dep on an old version that
doesn't actually include the needed feature).

The last option is what I suspect will happen, and that will be very
sad, since it seems unneeded. It will also make version management
hard for CD deployers (like TripleO's deploy-trunk default) because
incorrect requirements files are anaethema.

Markmc's mail about wanting the same rhythm doesn't make sense to me
since more than half the openstack artifacts *do not have* the 6 month
rhythm - client libraries have always been semver, release when ready.

AIUI the stable branches thing in the server space exists to give us
freedom to evolve the code super rapidly, in these large, fairly
monolithic APIs; we need it because we are always
backward-incompatible between server /releases/ (only of the server
HTTP API) - if we do semver, we'd be doing a breaking release every 6
months. So stable branches is a valve to balance trunk velocity of
independent codebases vs user demands for bugfixes and security fixes.

The other basic model we have as software releasers is to do stable
branches only when a backwards incompatible change has happened -
thats what we demand from projects like setuptools *and our client
libraries*: we want to be able to fork at that point, but the default
behaviour is not to fork, and instead just not break things.

"Not break things" is roughly proportional to the size of the
codebase, and the oslo projects are typically small focused projects
where this seems reasonable to expect. *More than that*, I believe its
essential, or we'll have a very hard time propogating new releases out
amongst the servers.

tl;dr there seems to be no reason to do one release every 6 months of
olso.*, and doing so seems likely to only incur costs, since the
discipline needed to do regular semver with good backwards compat is a
discipline we're going to have to exercise anyway.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



More information about the OpenStack-dev mailing list