geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: [discuss] branch and tag policy (and stable/unstable mixed in :)
Date Mon, 19 Sep 2005 19:43:15 GMT
I think we, the community, needs to decide if we want to maintain  
milestones going forward.  This would include "we shouldn't but we  
might want to..." (1)  If we are maintaining milestones, I think we  
should have the following structure:

branches/v1_0_M5
tags/v1_0_M5_0

This makes it clear to users that there may be an entry tags/v1_0_M5_1.

I personally don't think we should ever maintain something called a  
"milestone".  If we want to maintain the code we are calling  
"milestone 5" I think we should rename this code to "release 0.5.0",  
or we could just call it 1.0.0 :)

-dain


(1) This would not include exceptional, weird, or emergency cases.   
If something exceptional happens, we come together as a community and  
address the exceptional situation.

On Sep 19, 2005, at 11:55 AM, 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
> geirm@apache.org
>
>


Mime
View raw message