geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: [discuss] branch and tag policy (and stable/unstable mixed in :)
Date Mon, 19 Sep 2005 19:44:41 GMT

On Sep 19, 2005, at 3:05 PM, Aaron Mulder wrote:

> BTW, I think the implication that IBM has something to do with  
> deciding on a branching strategy is ridiculous.  But I don't know  
> who made it or why, so perhaps that's a premature statement on my  
> part.  :)

I brought it up to get it out in the open, as I heard it from at  
least two people - that they thought that someone might think there  
was some rationale like that, and I figured the best way to remove  
that issue from people's minds was to just shine light on it.

Poof - it disappeared :)


> Aaron
> On 9/19/05, Geir Magnusson Jr. <> wrote: This is a  
> subject with too much heat and smoke and weird accusations
> of commercial motivations to boot, so lets just have this out and
> keep moving.
> I have heard from two people that my position appears either entirely
> or partially influenced by IBMs interest in offering support for a
> milestone release, and thus I want to keep branches around so an
> update to a milestone can be done if someone wants it.  My only
> response, other than "baloney", is that because SVN keeps everything,
> we can always bring the branch back to do an update to a milestone,
> so wrt what IBM wants to do, it's moot.  The PMC dictates if a
> release happens, not the structure of SVN.
> So...
> I'd like to see a regular, formal policy for how we do branches and
> tags.  it makes it easier for newcomers to understand, and for us to
> create a process that outlives us.   We might as well rope in
> Jeremy's thoughts on a stable branch and an unstable branch a la
> Linux and Httpd as well.
> To me, a tag is a pointer to some branch.  It's a little different in
> SVN since SVN doesn't actually have branches and tags, but they are
> just fabricated because we're used to CVS.
> Will we ever let someone do an update to a release that was called
> "milestone"?  I see no problem in letting that happen if someone
> wants to do it, although I think it's highly unlikely.  I think that
> this issue is tangential to the discussion, because an update to a
> milestone is determined by PMC vote, not visible existence of a
> branch in SVN.
> Some people think we need no history for milestones, but the fact is
> that we are trying to get people to use our milestones (not just
> IBM), and I think that it behooves us to provide as good user support
> as possible, to the extent that some users want it.  Maybe we adopt
> an N-1 policy for milestones?  So if we release M5, we keep M4
> around, and delete M3, M2, M1.  if we release m6, we delete M4, etc.
> Now, Dain correctly points out that having both branches and tags is
> a waste of space.  So since mechanically branch and tag are the same
> thing (copies) can we just stop creating new branches altogether for
> releases, and have a trunk that we tag from?  Two approaches off  
> hand :
>    a) we work on our release candidate in trunk until we are
> satisfied, and then do a tag, do the final testing, and release
> that.  If it fails, we fix in trunk, and then tag, test and release.
> That means that dev has to slow down (or cease!) in trunk between tag
> time and release time.
>    b) We have a trunk/1.0 and trunk/1.1 where 1.0 is our released
> version and can fix and tag 1.0.x all we want without worrying about
> stopping work in trunk/1.1, while releasing new and zany stuff as our
> 1.1.x release stream.   Then when we are happy w/ 1.1, we make that
> 1.2 and 1.3 at the same time, and focus on 1.2.x as stable, and 1.3.x
> as dev updates.  I don't know how to start this off, actually,
> because we either could abandon the Mx thingy and do a 0.9 as we
> drive to 1.0, or just keep the Mx thingy and start w/ 1.0, 1.1
> When I was active with velocity, I would tag for a release, and just
> keep moving.  In the event we had to go backwards and do an update,
> we'd turn the tag into a branch, fix the branch, and then do a new
> tag and release.  This worked well, but over time, it became
> confusing, as some releases had branches, and some didn't.  That's
> why I'm interested in something regular and formal.
> Comments?  We've been around this issue a few times, and should just
> put it to rest in a way that makes us all satisfied.
> geir
> --
> Geir Magnusson Jr                                  +1-203-665-6437

Geir Magnusson Jr                                  +1-203-665-6437

View raw message