db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: Beta Announcement and encouraging user testing
Date Thu, 10 Aug 2006 16:52:44 GMT
If we can assume that nobody will be checking in fixes to the beta 
branch, and that therefore the "mega-merge" is a one-way operation with 
no manual conflicts to deal with, then I think this approach makes sense.



Rick Hillegas wrote:
> Thanks to everyone for thinking through the issues here. This has been 
> very helpful. I don't understand the practical advantages of a copy 
> versus a branch, particularly since I will have to create a branch 
> eventually. I could use some more education here. What would be the 
> objections to the following scheme? A big advantage to this scheme is 
> that it's something I can wrap my mind around:
> 1) I create a 10.2 branch.
> 2) I turn on the beta bit in that branch.
> 3) I generate the beta candidate from that branch.
> 4) In the meantime, bug fixes accumulate in the trunk.
> 5) At some point I mega-merge the trunk into the 10.2 branch based on a 
> triggering event:
>  a) triggered by the need to generate a new release candidate
>  b) triggered by the checkin of destabilizing work such as a partial 
> feature
> 6) After the mega-merge, fixes must be applied to both the trunk and the 
> 10.2 branch.
> Thanks again for helping me work through these issues.
> Regards,
> -Rick

View raw message