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 :) > 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. > >>> [...] > >>> 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 ? It's a branch for bugfix releases of the icehouse version of the library, so I think stable/icehouse makes sense. Mark. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev