[RELEASE] branching and tagging the components

Hugh Brock hbrock at redhat.com
Tue Nov 20 16:28:23 UTC 2012


On Tue, Nov 20, 2012 at 05:12:15PM +0100, Giulio Fidente wrote:
> hi Steven
> 
> On 11/20/2012 05:04 PM, Steve Linabery wrote:
> > It's certainly not a 'proper' release, with docs, release announcement, description of what other components are required (factory, et al).
> 
> agreed, I was trying to find out if and how the tags/branches of the
> components relate to each other (inclunding factory, oz, cli, maybe TIM
> at some point in the future)
> 
> >> Also, do you see the idea of tagging all the components with the same
> >> tag a valid approach or are there different suggestions?
> > 
> > What I would like to see on an actual upstream release is:
> > 1) create maintenance branch and tag on that branch
> > 2) bump version number on master branch for ongoing development
> 
> to be honest, I'm not sure what are the best practices for such a
> complex project where we want to merge the development efforst from
> different components, but your looks to me a good approach
> 
> devs, any hint on this?

It's a tough problem.

Ultimately I think three things need to happen.

1. Each separate upstream needs to be fully testable in isolation from
its dependencies -- i.e. fully mocked out. We have made some progress
towards this, I'm not sure if it's complete or not.

2. An upstream with dependencies needs to be integration tested against
known-good versions of its dependencies. It's probably a Release Cabal
function to decide what the "stable" versions of deps are and approve
revisions to those as part of release planning.

3. As far as automated testing goes, it seems to me we ought to
continuously test changes to each upstream project, but not more than
one at a time. In other words, Conductor gets CI run against HEAD, but
with known-good deps. If Conductor requires a dependency updated (newer
Deltacloud, e.g.) then that Deltacloud version should become the
known-good for the whole project -- or the Conductor dependency update
shouldn't be allowed in.

Does that make any sense?

--Hugh

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey



More information about the aeolus-devel mailing list