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 Wed, 09 Aug 2006 23:56:08 GMT
I don't believe doing a beta off the trunk implies features can't be 
checked in after the snapshot is made.  I don't believe it's right to 
try to enforce such a restriction on the trunk.

My understanding of what Andrew describes is that you can cut a branch 
later and reverse-merge the feature changes out, or go back in 
revision-time and cut a branch from a point before the feature was 
checked in and then merge over all subsequent bug fixes.

I understand Dan's concern about doing a beta snapshot off of the trunk 
(e.g. "the trunk is for cutting-edge stuff").  But if the majority of 
work happening on the trunk over the next few weeks is going to be 
maintenance work and nobody is planning on going pell mell with new 
features, then I think it's more manageable for us to stay on the trunk 
rather than "swim with weights" as Rick puts it by cutting a branch for 
our first beta snapshot and having to merge every subsequent bugfix over 
to the branch.

But if committers are planning on committing a lot of new feature work 
or other destabilizing changes into the trunk over the next few weeks, 
we should probably cut a branch.

David

Rick Hillegas wrote:
> Daniel John Debrunner wrote:
> 
>> Rick Hillegas wrote:
>>
>>  
>>
>>> Hi Andrew,
>>>
>>>
>>> Andrew McIntyre wrote:
>>>
>>>   
>>>> On 8/9/06, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
>>>>
>>>>     
>>>>> Hi David,
>>>>>
>>>>> I think there's a significant delta between the last snapshot and the
>>>>> beta I plan to cut imminently. I would recommend that people wait for
>>>>> the beta.
>>>>>       
>>>>
>>>> Are you planning do the beta out of the trunk? I don't think there's a
>>>> need to branch until there's actually potential for release. It'll
>>>> save a lot of merging.
>>>>     
>>> I think this is a great idea. I will just cut the beta off the trunk.
>>>   
>>
>> What exactly is the plan here, people have been throwing around beta but
>> I don't know what that means in this context? Are you going to change
>> the version information so Derby reports itself as beta? Doing that on
>> the trunk just seems wrong, maybe it's ok, but isn't the trunk always
>> alpha, cutting edge, etc?
>>
>> Confused,
>> Dan.
>>
>>  
>>
> Here are the options so far. I've never done this before so I'm grateful 
> for advice from those who have already been down this road:
> 
> 1) Create a branch and change the version information so that Derby 
> reports itself as beta.
> 
> + It's clear that the the built code is beta.
> - Bug fixes must be tested/committed to two codelines.
> 
> 2) Continue working in the trunk.
> 
> + For a week or two longer we only have to test and commit in one codeline.
> - Requires that committers not check in partial features for a week or two.
> - The beta candidate says that it is alpha.
> 
> 3) Continue working in the trunk but mark the version as beta.
> 
> + For a week or two longer we only have to test and commit in one codeline.
> - Requires that committers not check in partial features for a week or two.
> - The trunk says it is beta, which may be confusing.
> 
> 4) Other options?
> 
> I would appreciate guidance from the community about which of these 
> options seems least onerous and/or confusing.
> 
> Thanks,
> -Rick
> 

Mime
View raw message