[openstack-dev] [oslo] versioning and releases

Doug Hellmann doug.hellmann at dreamhost.com
Thu Jun 12 19:33:13 UTC 2014

On Thu, Jun 12, 2014 at 12:03 PM, Thierry Carrez <thierry at openstack.org> wrote:
> 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

At first I didn't want to bother with alpha releases, because they
introduce a special case. I've since come around to the same line of
thinking as Mark, especially now that releasing alphas works without
having to point to tarballs in requirements files.

>>> 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)
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list