On Jul 4, 2012, at 11:18 AM, David Nalley wrote:
> On Wed, Jul 4, 2012 at 1:49 PM, John Kinsella <j...@stratosec.co> 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
>> sf.net 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
http://wiki.cloudstack.org/display/COMM/Draft%3A+CloudStack+Maintainers+Guide,
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...
John
