[RELEASE] branching and tagging the components

Michael Orazi morazi at redhat.com
Tue Nov 20 17:04:16 UTC 2012



----- Original Message -----
> 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
> > 
> > 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).
> 
> s|e
> 

To refine the fantasy oh so slightly, it is a tag name per repo/project.  They can potentially be distinct and we can't enforce a naming convention across all the repos (I'm thinking imgfac in particular is really working hard to become more firmly entrenched upstream and may have their own process/procedure around tagging).

One thing that keeps flitting through my brain but not staying long enough to determine if it is a good idea or not is that it might be handy to have a 'meta-tag' to simplify picking the appropriate tags for all the sub-projects and pushing that information into a dev_tools run.

> > devs, any hint on this?
> > --
> > Giulio Fidente
> 



More information about the aeolus-devel mailing list