[RELEASE] branching and tagging the components

Steve Linabery slinaber at redhat.com
Tue Nov 20 17:00:34 UTC 2012


On Tue, Nov 20, 2012 at 05:52:32PM +0100, Jiří Stránský wrote:
> On 20.11.2012 17:31, Steve Linabery 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)
> >
> >Yes, that aspect is definitely missing from the end of sprint release.
> >
> >We should document at end of sprint (on wiki or elsewhere, even if it's not an actual release) what other components' version/release info was.
> >
> >>
> >>>>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
> 
> +1. This makes uninterrupted development on master possible, which is what I was calling for in my talk at the dev conference.

Yes. It also allows us to backport fixes to official releases if we want.

> 
> >>
> >>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
> >>
> >
> >In my fantasy world, dev-tools takes a tag name (or a URL to a config that we post as part of the release) and grabs/installs all the right components. We discussed this approach in our last meeting, but since then I have mentioned the idea to Crag Wolfe, who seemed open to the idea (while acknowledging that there is a lot of work to do before dev-tools can do that sort of thing for us).
> 
> +1 on that too. Having automated tools that can set up an upstream release stack of Aeolus would be great. So if I understand correctly, the dev-tools should eventually be able to install both development and production versions of Aeolus (for distros that will not have Aeolus rpms/debs), since it should be just a matter of switching the tag/branch.
> 

Yeah, my half-baked idea was to have, as part of the release documentation, a config file that defines necessary ENV variables to point to the right branches on all the components. So maybe you'd set (contrived example) RELEASE_CONFIG=http://aeolusproject.org/releases/X.Y.Z/dev-tools-environment.yml and dev-tools takes it from there.

s|e

> >
> >s|e
> >
> >>devs, any hint on this?
> >>--
> >>Giulio Fidente
> 



More information about the aeolus-devel mailing list