Open Stack

Doug Hellmann wrote:
> On Tue, Jun 10, 2014 at 5:19 PM, Mark McLoughlin <markmc at redhat.com> wrote:
>> On Tue, 2014-06-10 at 12:24 -0400, Doug Hellmann wrote:
>> [...]
>>> Background:
>>>
>>> We have two types of oslo libraries. Libraries like oslo.config and
>>> oslo.messaging were created by extracting incubated code, updating the
>>> public API, and packaging it. Libraries like cliff and taskflow were
>>> created as standalone packages from the beginning, and later adopted
>>> by the oslo team to manage their development and maintenance.
>>>
>>> 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.

Could you outline the benefits of syncing with the integrated release ?

Personally I see a few drawbacks to this approach:

We dump the new version on consumers usually around RC time, which is
generally a bad time to push a new version of a	dependency and detect
potential breakage. Consumers just seem to get the new version at the
worst possible time.

It also prevents from spreading the work all over the cycle. For example
it may have been more successful to have the oslo.messaging new release
by milestone-1 to make sure it's adopted by projects in milestone-2 or
milestone-3... rather than have it ready by milestone-3 and expect all
projects to use it by consuming alphas during the cycle.

Now if *all* projects were continuously consuming alpha versions, most
of those drawbacks would go away.

>>> [...]
>>> Patch Releases:
>>>
>>> Updates to existing library releases can be made from stable branches.
>>> Checking out stable/icehouse of oslo.config for example would allow a
>>> release 1.3.1. We don't have a formal policy about whether we will
>>> create patch releases, or whether applications are better off using
>>> the latest release of the library. Do we need one?
>>
>> I'm not sure we need one, but if we did I'd expect them to be aligned
>> with stable releases.
>>
>> Right now, I think they'd just be as-needed - if there's enough
>> backported to the stable branch to warrant a release, we just cut one.
> 
> That's pretty much what I thought, too. We shouldn't need to worry
> about alphas for patch releases, since we won't add features.

Yes, I think we can be pretty flexible about it. But to come back to my
above remark... should it be stable/icehouse or stable/1.3 ?

-- 
Thierry Carrez (ttx)