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-environm... and
dev-tools takes it from there.
s|e
>
>s|e
>
>>devs, any hint on this?
>>--
>>Giulio Fidente