geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Where did the 1.1 branch go?!?!
Date Sun, 18 Jun 2006 20:30:06 GMT
David Blevins wrote:
>
> On Jun 15, 2006, at 2:18 PM, Alan D. Cabrera wrote:
>
>> David Blevins wrote:
>>>
>>> On Jun 15, 2006, at 12:22 PM, Alan D. Cabrera wrote:
>>>
>>>> David Blevins wrote:
>>>>>
>>>>> On Jun 15, 2006, at 11:48 AM, David Blevins wrote:
>>>>>
>>>>>>
>>>>>> On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote:
>>>>>>
>>>>>>> David Jencks wrote:
>>>>>>>> -0.5 to copying branches/1.1 to branches/1.1.x and then copying

>>>>>>>> or moving to tags/1.1.x  Since ONLY BUG FIXES can possibly
be 
>>>>>>>> added to branches/1.1, this should not cause problems.  The

>>>>>>>> release manager gets say over what goes into a release, they

>>>>>>>> can revert changes they don't want in the release.  I think
the 
>>>>>>>> copy to branches/1.1.x just adds steps for no gain.
>>>>>>> I would upgrade this to a -1 on my part.
>>>>>>
>>>>>> Think you're getting kind of nit-picky on what you think is 
>>>>>> easiest for a release manager to do.  I'd rather see us simply 
>>>>>> agree on what the end result should be.
>>>>>>
>>>>>> IMHO, if a release manager wants to copy into a temp location 
>>>>>> while they finalize the release (which can take days) to remove 
>>>>>> the risk of having to roll back accidental changes, that's fine.
>>>>>>
>>>>>
>>>>> Actually, now that i think about it there is one more reason other 
>>>>> than preference that I like making a branches/1.1.0 for release 
>>>>> finalization.
>>>>>
>>>>>  -- branches/1.1 will never have geronimo_version=1.1 and people 
>>>>> (including continuum) won't have fake 1.1 final jars in their repos.
>>>> Why do we need geronimo_version=1.1 in branches/1.1.0?  Sorry, I'm 
>>>> not following.
>>>
>>> Let me add the the item below and see if it doesn't make more sense.
>>>
>>> 1.    cp branches/1.1 to branches/1.1.0
>>> 2.    in branches/1.1.0
>>> 2.1   geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1
>>> 2.2   update plugin version numbers
>>> 2.3   update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1
>>> 3.    in branches/1.1
>>> 3.1   geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1.1-SNAPSHOT
>>> 3.2   update plugin version numbers
>>> 3.3   update any hard coded poms or plans from 1.1-SNAPSHOT to 
>>> 1.1.1-SNAPSHOT
>>> 4.    eventually move branches/1.1.0 to tags/1.1.0 when release is 
>>> actually final
>>>
>>> Make more sense?
>> Yeah, but you still haven't explained why we need both to exist 
>> concurrently.
>>
>
> Takes at least a week from code freeze till shipping day.
Ok, I have two problems with this.  First, I didn't come up with the 
idea first.  Second, it would actually mean that Aaron and I actually 
have common ground on release procedures.  :)

Sounds good to me so long as *ONLY* bugs go into that branch.  Given 
that, I wonder if we should go a four level version number:

major.minor.trivial.patch


Regards,
Alan




Mime
View raw message