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.hellm...@dreamhost.com> wrote: > On Thu, Jun 12, 2014 at 12:03 PM, Thierry Carrez <thie...@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 <mar...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
