db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathy Saunders <kat...@mtrad.com>
Subject Re: Proposal for 10.2 release schedule
Date Tue, 27 Jun 2006 20:49:57 GMT
Rick Hillegas wrote:

> Thanks, Kathy. I think I'm getting the message that the following 
> would be an acceptable and more traditional schedule:
>
> August 10 : Last feature work commits
> August 11 : First release candidate generated
> August 24 : Second release candidate generated
> September 7: Third and hopefully last release candidate generated
> September 15: Targetted end of voting on release candidates
>
> Is this a realistic schedule or is it still too aggressive?
>
> Thanks,
> -Rick


In my opinion that is a reasonable schedule.  Of course, number of 
release candidates and final dates are dependent on the quality of  the 
code.  But, based on what I've seen with Derby releases so far, this 
timeframe seems like it can work.

Hopefully the licensing issues will be resolved prior to August 10 as well.

>
> Kathy Saunders wrote:
>
>> Rick Hillegas wrote:
>>
>>> Thanks, Rajesh. In your scheme, when should feature work on 10.2 
>>> wrap up? I had budgeted 2 weeks between the end of feature work and 
>>> the first release candidate. Is that overkill? Should we propose 
>>> that feature work wraps up by, say, July 27?
>>
>>
>>
>> Do we need to have a feature wrap up and then time to do  more 
>> development?  Can't we just say that all planned work--features, bug 
>> fixes, etc. should be done by August 10?  Then you could post the 
>> first RC on August 11 or shortly after that. It's true that feature 
>> check-ins might cause some bugs that need to be dealt with, but those 
>> can be dealt with in RC2 if need be.
>>
>> Kathy
>>
>>>
>>> Rajesh Kartha wrote:
>>>
>>>> Rick Hillegas wrote:
>>>>
>>>>> Last week, Sun Microsystems announced that it will bundle Derby 
>>>>> with the next major release of the reference jdk, Java SE 6, also 
>>>>> known as Mustang or jdk1.6. If you download the latest Mustang 
>>>>> build, you will see that it contains our Derby 10.2.0.3 snapshot 
>>>>> in the "db" directory parallel to "lib" and "bin".
>>>>>
>>>>> This is big news. It means that over the course of the next year, 
>>>>> Derby will turn up on the desktops of millions of developers. 
>>>>> Hopefully, Derby's user and developer communities will both grow 
>>>>> dramatically.
>>>>>
>>>>> I would like to support this bundling. Note that Mustang will need 
>>>>> our vetted 10.2 release candidate by September 15 so that they can 
>>>>> QA it. This is expected to take about 5 weeks, after which Mustang 
>>>>> should go GA in late October.
>>>>>
>>>>> The JCP requires that our JDBC4-exposing release can not be 
>>>>> generally available until the JDBC4 specification is finalized, 
>>>>> which happens when Mustang is generally available. Until that 
>>>>> date, this means that our final, vetted release candidate can not 
>>>>> be officially stamped as "GA"  and we can not promote it to the 
>>>>> various Apache mirrors.
>>>>>
>>>>> Here are proposed dates for 10.2 milestones:
>>>>>
>>>>> August 10 - Feature work committed. 10.2 branch created.
>>>>> August 24 - Last day to commit changes for 10.2
>>>>> August 25 - Begin vetting 10.2 release candidate
>>>>> September 15 - Target date for finishing the voting on Derby 10.2
>>>>> End of October - Expected GA of JDBC4 with Mustang
>>>>> End of October - GA of Derby 10.2. Release promoted to Apache 
>>>>> mirrors.
>>>>>
>>>>> Are this proposal and its dates reasonable?
>>>>>
>>>>>
>>>> Hi Rick,
>>>>
>>>> On careful review of the dates you posted, it looks like the time 
>>>> frame for testing is just about 3 weeks (Aug 25 - Sept 15).  10.2 
>>>> being a major release with lots
>>>> of new features/fixes,  we need to make sure there is enough time 
>>>> for the community to test the release and 3 weeks sure seems less.
>>>> My experience during all the previous releases of Derby is that  we 
>>>> invariably had multiple release candidates - hence the 10.2 testing 
>>>> time frame
>>>> needs to take this into account.
>>>>
>>>> I suggest one of the following two:
>>>>
>>>> 1) Keep the date to complete voting for Derby 10.2 as Sept 15:
>>>>
>>>>   To achieve this,  we move the last day to commit changes early, 
>>>> which would mean:    August 10 - Last day to commit changes for 10.2
>>>>    August 11 - Release Candidate 1 ready for testing
>>>>    September 15 - Target date for finishing the voting on Derby 10.2
>>>>
>>>> 2)  Push the date to complete voting for Derby 10.2 to Oct 2:
>>>>       August 24 - Last day to commit changes for 10.2
>>>>    August 25 - Begin vetting 10.2 release candidate
>>>>    Oct 2nd - Target date for finishing the voting on Derby 10.2
>>>>      This will give us  about 5 weeks in both the cases, within 
>>>> which we can provision for RC2 if needed.
>>>>
>>>> Let me know what you think.
>>>>
>>>> Regards,
>>>> Rajesh
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>



Mime
View raw message