Open Stack

Since I think we have consensus on this, I have published a slightly
modified version (cleaning up verb tense and clarifying how Juno and
post-Juno will differ) to the wiki:
https://wiki.openstack.org/wiki/Oslo/VersioningPolicy

On Thu, Jun 12, 2014 at 3:33 PM, Doug Hellmann
<doug.hellmann at dreamhost.com> wrote:
> 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