[RELEASE] branching and tagging the components

Steve Linabery slinaber at redhat.com
Tue Nov 20 17:16:14 UTC 2012


On Tue, Nov 20, 2012 at 12:04:16PM -0500, Michael Orazi wrote:
> 
> 
> ----- 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.

Yeah, that was what I was trying to get at (sort of) with my 'set of ENV variables in a config file, hosted on aeolusproject.org associated with a particular set of release docs' idea.

IOW, we'd have a canonical doc up there that defined component:tag for all the components that constitute a working release.

Am I making any sense? :)

s|e

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



More information about the aeolus-devel mailing list