geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: [discuss] branch and tag policy (and stable/unstable mixed in :)
Date Mon, 19 Sep 2005 19:05:32 GMT
Actually, IIUC, branches and tags don't waste space (at least, not on the 
server). SVN doesn't create copies of the files in the repo until they are 
actually changed vs the source of the copy (which for a "tag" would be 

For my part, I don't understand why we don't keep branches alive forever, or 
at least until we vote on discontinuing support for the release the branch 
is tied to. We can vote to trash M4 in favor of M5 if we like, but I don't 
think 24 hours and <5 votes is enough to say the issues was decided.

As for the confusion of branches and tags, Dain, can you clarify if your 
confusion is caused strictly by this being a milestone release? I mean, if 
this was the v3.2 branch, and we had a v3.2.0 tag while the 3.2 branch HEAD 
was used for development toward 3.2.1, would that be confusing? I think 
that's the approach we have to take, and whacking the 3.2 branch as soon as 
3.2.0 was released with the intention of "resurrecting it" if we ever 
decided to work on 3.2.1, well, that doesn't make any sense to me. But of 
course there is no M4.0 and M4.1 so the whole issue is kind of muddy 
regarding milestones, and I don't really care what we do to the M-series.

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. :)


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

View raw message