Open Stack

Mark McLoughlin wrote:
> On Thu, 2014-06-12 at 12:09 +0200, Thierry Carrez wrote:
>> 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 ?
> 
> Sure!
> 
> http://lists.openstack.org/pipermail/openstack-dev/2012-November/003345.html
> 
> :)

Heh :) I know why *you* prefer it synced. Was just curious to see if
Doug thought the same way :P

>> 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.
> 
> Yes, that's the plan. Those issues are acknowledged and we're reasonably
> confident the alpha versions plan will address them.

I agree that if we release alphas often and most projects consume them
instead of jump from stable release to stable release, we have all the
benefits without the drawbacks.

-- 
Thierry Carrez (ttx)