Open Stack

On 11/22/2012 09:44 AM, Mark McLoughlin wrote:
> On Tue, 2012-11-13 at 15:19 +0100, Thierry Carrez 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.
>
> (snip good summary, agree we can't assume same solution as client
> libraries works here)
>
>>> 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?
>>
>> 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, it's not required, but I think there's some value in a checkpoint
> release of all the libraries in the same family using the same version.
> It would just make it easier for folks to understand which versions
> belong together, given they will be dependent on each other.
>
>>> 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.

Let's assume we'll figure out the PyPI question, even if it looks weird. 
There are examples of other projects using multiple release streams to 
pypi we can examine (this has a different consumption usecase than the 
client libs, so I think my objections to stable releases there doesn't 
apply here)

> Well, to add two more questions:
>
>    * When do we commit to compatibility around a new API in Oslo? When
>      it gets committed, when it gets released or when we release an
>      officially "API frozen" version?

I vote for when it gets released.

>    * How do other OpenStack projects consume Oslo libraries during
>      development? e.g. can you put a git URL into pip-requires, or must
>      you have a pypi release version there?
>
> You could say e.g. new APIs are committed to when they're released to
> pypi and OpenStack projects can only consume new APIs once they've been
> released to pypi.

Yes please. We have done cross-project git-url consumption before. It's 
a nightmare (largely because although the python toolchain tempts us 
into thinking this will work, it doesn't actually fully work.

> But that could result us doing library releases too often, integration
> with other projects being too slow or us only realizing we've made
> drastic API design mistakes after committing to the new API.

Honestly, I think you have a slightly easier time of it than the client 
lib folks in terms of API commitment - since you know who your consumers 
are, and you can actually check around to see if anyone is using an old 
API. It's not too terrible - how about we try it that way for a bit and 
see if there are actual logistical problems?

Monty