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 >
