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 > >
