milestone branching and taging (was Re: svn commit: r226882 - in /geronimo: branches/v1_0_M4-QA/ tags/v1_0_M4/)

[David Blevins <da...@visi.com>]

On Wed, Aug 03, 2005 at 09:04:22AM -0400, Geir Magnusson Jr. wrote:
> 
> On Aug 2, 2005, at 9:41 PM, David Blevins wrote:
> 
> >On Mon, Aug 01, 2005 at 07:16:23PM -0400, Geir Magnusson Jr. wrote:
> >
> >>no, you moved...
> >>
> >>we never want to move branches, but copy to make tags, and never
> >>modify the tags.  That way, if we need to keep going on the branch,
> >>we have it.
> >>
> >
> >We agreed on this proceedure a month ago.
> 
> Clearly we agreed on a mistake then.  I didn't read it carefully.   
> Sorry.
> 
> We want to be able to branch, work on the branch, and then tag for a  
> release (call it vX.0) Nothing in the tag is different from the  
> branch it came from - it's effectively a pointer to a moment in time  
> (revision) on the branch.
> 
> Now, suppose we have a security issue for which we want to do an  
> update on the thing we released.  So we then must go back to the  
> *branch*, fix the bug, tag again (vX.0.1).
> 

You've described my ideal setup for 1.0 and beyond, but we aren't
doing dot releases yet.  

There is never going to be another release from the M4-QA branch.
It's a dead branch and shouldn't be updated after we vote to release
the M4 binaries.

-David

Re: milestone branching and taging (was Re: svn commit: r226882 - in /geronimo: branches/v1_0_M4-QA/ tags/v1_0_M4/)

[Aaron Mulder <am...@alumni.princeton.edu>]

On Wed, 3 Aug 2005, David Blevins wrote:
> You've described my ideal setup for 1.0 and beyond, but we aren't
> doing dot releases yet.  
> 
> There is never going to be another release from the M4-QA branch.
> It's a dead branch and shouldn't be updated after we vote to release
> the M4 binaries.

	I'm OK with deleting a branch *after* the release has been voted 
and distributed.  But since we have to make the tag before that, I really 
don't like deleting the branch when making the tag.  Why do you object to 
making the tag a *copy* of the branch?

Aaron

Re: milestone branching and taging (was Re: svn commit: r226882 - in /geronimo: branches/v1_0_M4-QA/ tags/v1_0_M4/)

["Alan D. Cabrera" <li...@toolazydogs.com>]

Geir Magnusson Jr. wrote, On 8/3/2005 1:57 PM:

>
> On Aug 3, 2005, at 4:14 PM, David Blevins wrote:
>
>> On Wed, Aug 03, 2005 at 09:04:22AM -0400, Geir Magnusson Jr. wrote:
>
>> There is never going to be another release from the M4-QA branch.
>> It's a dead branch and shouldn't be updated after we vote to release
>> the M4 binaries.
>
>
> Why wouldn't we set a process that's standard and stick with it?
>
> Further, it's entirely reasonable to keep our option open for a  
> subsequent release of M4.  Remember M3?  And what if we find a major  
> problem?  We don't want to ram forward a M5 - we'd want to fix M4 and  
> get that out there, retracting the problematic release, say a M4r1.

This makes sense to me.


Regards,
Alan

Re: milestone branching and taging (was Re: svn commit: r226882 - in /geronimo: branches/v1_0_M4-QA/ tags/v1_0_M4/)

["Geir Magnusson Jr." <ge...@apache.org>]

On Aug 3, 2005, at 4:14 PM, David Blevins wrote:

> On Wed, Aug 03, 2005 at 09:04:22AM -0400, Geir Magnusson Jr. wrote:
>
>>
>> On Aug 2, 2005, at 9:41 PM, David Blevins wrote:
>>
>>
>>> On Mon, Aug 01, 2005 at 07:16:23PM -0400, Geir Magnusson Jr. wrote:
>>>
>>>
>>>> no, you moved...
>>>>
>>>> we never want to move branches, but copy to make tags, and never
>>>> modify the tags.  That way, if we need to keep going on the branch,
>>>> we have it.
>>>>
>>>>
>>>
>>> We agreed on this proceedure a month ago.
>>>
>>
>> Clearly we agreed on a mistake then.  I didn't read it carefully.
>> Sorry.
>>
>> We want to be able to branch, work on the branch, and then tag for a
>> release (call it vX.0) Nothing in the tag is different from the
>> branch it came from - it's effectively a pointer to a moment in time
>> (revision) on the branch.
>>
>> Now, suppose we have a security issue for which we want to do an
>> update on the thing we released.  So we then must go back to the
>> *branch*, fix the bug, tag again (vX.0.1).
>>
>>
>
> You've described my ideal setup for 1.0 and beyond, but we aren't
> doing dot releases yet.
>

It shouldn't matter.

> There is never going to be another release from the M4-QA branch.
> It's a dead branch and shouldn't be updated after we vote to release
> the M4 binaries.

Why wouldn't we set a process that's standard and stick with it?

Further, it's entirely reasonable to keep our option open for a  
subsequent release of M4.  Remember M3?  And what if we find a major  
problem?  We don't want to ram forward a M5 - we'd want to fix M4 and  
get that out there, retracting the problematic release, say a M4r1.

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org