Open Stack

Mark McLoughlin wrote:
> One question I had on that is re:
> 
>   the ability to release a client library outside of the core project 
>   release cycle (requests have been coming in to our release manager for
>   this)
> 
> Who were these request from and why? That would help understand what
> we're trying to do here.

A bit of history would help.

Originally the client library projects were independent and were
released by their author to PyPI. People built their tooling and
automation around the capability for PyPI to fetch the version they
needed (I don't really support that, but apparently that's what most
devs do). So any time someone needed to access a new feature, they would
ask the author for a new PyPI release. It resulted in a lot of
confusion, as the projects on PyPI were maintained by a number of folks
and some of them were a bit unmaintained.

Then we realized that the client libraries were needed by core projects
(Nova -> Glance, Nova -> Nova zones, Horizon, Glance -> Swift, etc.)
while they were not "OpenStack". Rather than creating a bunch of new
core projects, the PPB decided to consider them as "separate release
deliverables" of the corresponding server project, inheriting its PTL
and Launchpad project.

However they also inherited the release scheme of the server project
(new version every 6 months), which was (or was not) synced to PyPI
depending of who was owning the PyPI project. More confusion as PyPI
rarely contained the just-released version, since releasing to PyPI was
not handled by OpenStack release management.

People kept on asking for new PyPI releases to access recent features.
Sometimes it's just that they need an early version of the client
somewhere to start integrating it before the milestone hits
(cinderclient, swiftclient). A release every 6 months is not enough.
Should PyPI only get releases ? or milestones ? or dailies ? And PyPI
does not support pre-versioning (2012.2~DATE) in the same way the server
does. For example there is no way to version our milestones in PyPI.

For all those reasons, it appears to be simpler to revisit the decision
of sharing versioning and release scheme with the server project. The
client library is a separate project anyway, with its own rewrites, APIs
etc. Conflating the two (like sharing projects in Launchpad) led to
confusion.

> In any case, my tl;dr suggestion is:
> 
>   1) The client libs get released along with OpenStack releases and 
>      versioned the same.
> [...]
>   2) We also include client libs in milestone releases, for people 
>      wanting to use the libs against development releases of OpenStack. 

That's the current situation, and as explained above it puts us in a
very difficult spot with releasing to PyPI. There is no elegant way for
client libraries to follow OpenStack Core versioning and be often
released with a version number that makes sense on PyPI. On the other
hand, Monty's solution solves that. So I'd reverse the question: what
would be the killer benefit of keeping on doing the same thing ?

I see only one: clear match between client and supported server version.
I think that can be documented, or we can use a versioning logic that
makes that very apparent, while still using a clearly separate release
scheme for client libraries.

Basically the benefit of solving our long-standing issues with releasing
on PyPI and clearing all the confusion those create sounds more
important to me.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack