geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Where did the 1.1 branch go?!?!
Date Thu, 15 Jun 2006 21:24:57 GMT
On Jun 15, 2006, at 1:37 PM, Aaron Mulder wrote:

> I would still make the last step *copy* branches/1.1.0 to tags/1.1.0
> when release is "final".  We can then either leave the 1.1.0 branch
> there in case of emergency fixes that preempt 1.1.1 or we can delete
> it once the release has hit the mirrors (at which time there's
> presumably no chance of wanting to recut or add one more license file
> or whatever).

You mean:

svn cp branches/1.1.0 tags/1.1.0
svn rm tags/1.1.0       ## oops, found a but
svn ci branches/1.1.0   ## fix something
svn cp branches/1.1.0 tags/1.1.0   ## retag
svn rm branches/1.1.0   ## tags/1.1.0 shipped

vs.

svn mv branches/1.1.0 tags/1.1.0
svn mv tags/1.1.0 branches/1.1.0   ## oops, found a bug
svn ci branches/1.1.0   ## fix something
svn mv branches/1.1.0 tags/1.1.0   ## retag

Does it really matter?

-David

> But that's a small issue and generally, I'm in full agreement with
> your proposal.
>
> Thanks,
>    Aaron
>
> On 6/15/06, David Blevins <david.blevins@visi.com> 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?
>>
>> -David
>>
>>
>>
>>
>>
>>
>


Mime
View raw message