Open Stack

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

:)

> 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.