incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Kinsella <>
Subject Re: ASF repo tags
Date Wed, 04 Jul 2012 19:08:37 GMT
On Jul 4, 2012, at 11:18 AM, David Nalley wrote:
> On Wed, Jul 4, 2012 at 1:49 PM, John Kinsella <> wrote:
>> Can we add git tags for the 3.0.0, 3.0.1, and 3.0.2 releases? I realize they're not
ASF-blessed releases, but would be very handy for when folks want to grab a particular release
from the repo.
>> I think 3.0.0 is cf0a4e02743abb87b665ea585cb3cf1786c4d966? The zip file on
mentions bcc4833 but I don't see that as a rev. I haven't tracked down the other two, yet.
> There in lies the problem.
> Typically the branching methodology would work something like this:
> master would be where cutting edge development would happen - for
> really big features or major rewrites
> Each release series would have it's on branch 3.0.x for the 3.0 series
> and 2.2.y for the later 2.2 series.
> Features would be introduced into those branches directly (and
> cherrypicked into master).
> As a release drew near, each release would branch as well so ongoing
> work could happen as well. So you'll see branches in the old repo for
> 3.0.{1,2,3} etc. During this phase work should be checked into 3.0.2,
> 3.0.x, and master.

I agree with the idea of branches for point releases (3.0,3.1,3,2..) but not sure we need
separate branches for minor releases? I guess it comes back to what CS agrees to maintain
and for how long. With the current wording on,
we're not doing any maintenance on releases, but fixing issues going forward...

> However, several factors complicate that. First,
> not all patches applied cleanly as the three different codebases were
> often in very different places. Second, people are human, and I
> imagine some commits just didn't make it.

Sounds like something a tool would help with, but I don't know of said tool…plugin for Jenkins,
maybe? Seems like it shouldn't be too hard to look for similar commits to 2 different branches.

Would this maybe be something that falls under a Maintainer to manage? e.g. for the Agent
Maintainer, make sure /agent patches are applied to the last 3 release branches?

Branch management may take us a little more work, but I think it'd be pretty easy as part
of release management to tag the revision that was used to build that release...


View raw message