Open Stack

Monty Taylor wrote:
> On 11/22/2012 09:44 AM, Mark McLoughlin wrote:
>> On Tue, 2012-11-13 at 15:19 +0100, Thierry Carrez wrote:
>>>> 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.

IMHO that would add a lot of versioning constraints for little gain. We
can describe oslo interdependencies using the same mechanism as other
libraries.

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

There seem to be two options there: just push everything on the same
PyPI module, or have multiple PyPI modules for each series. I'd say the
latter looks worse. For the former, I suspect you can specify ">=1.2.1
<2" as far as dependencies are concerned.

What's missing then is a sane view of the tree of available versions,
but if we upload the same tarballs to PyPI and Launchpad, we can present
a series-oriented view of the tree of versions that makes a lot more
sense. We did not really do that (yet) for client libraries because they
use a single series, so the gain of also uploading to LP is not as
obvious. Oh and, I'm slacking and did not write that auto-upload-to-LP
script to hook into CI yet.

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

That's a lot of questions, let's try to explore options and see how dumb
they sound...

I can picture one option where we would version oslo libraries
separately, based on classic major.minor.patch format. We could make
"stable branches" based off major versions. That would be separate from
the common development cycles and milestones, even if for planning (and
summit) reasons you would still talk about "grizzly development
timeframe", and try to slow down towards the end of the cycle. We can
push all versions to PyPI and use ">=1.2.1 <2" style to solve the
dependency specification... and push to Launchpad in parallel to provide
a sane, series-oriented view of the same deliverables.

How does that sound ?

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack