geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject [discuss] branch and tag policy (and stable/unstable mixed in :)
Date Mon, 19 Sep 2005 18:55:52 GMT
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.


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 Magnusson Jr                                  +1-203-665-6437

View raw message