[RELEASE] branching and tagging the components

Jiří Stránský jstransk at redhat.com
Tue Nov 20 17:11:36 UTC 2012


On 20.11.2012 17:28, Hugh Brock wrote:
> 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?

It does to me. Seems like a lot of testing, but since we are splitting into smaller subprojects, it might be necessary. So far Aeolus was bunch of relatively stable components with Conductor being the only unstable one, so point (3) was probably not necessary till now. But with Tim and Alberich being cut out and Winged Monkey joining soon, there are going to be more connections between potentially unstable projects, so (3) seems to me as a good idea too.

(1) is the tests we already have, but I wonder how (2) is going to be done. Will it be run on developers' machines, or only on CI? Are we going to enforce that code not passing (2) doesn't get pushed? (I think Travis won't let us do (2), will it?)

J.

>
> --Hugh
>




More information about the aeolus-devel mailing list