db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Proposal for 10.2 release schedule
Date Thu, 22 Jun 2006 21:59:09 GMT
Rick Hillegas wrote:

> Daniel John Debrunner wrote:
>
>> Rick Hillegas wrote:
>>
>>  
>>
>>> Hi Dan,
>>>
>>> Thanks for your comments. Some further remarks follow.
>>>
>>> Regards,
>>> -Rick
>>>
>>> Daniel John Debrunner wrote:
>>>
>>>   
>>>
>>>> Rick Hillegas wrote:
>>>>
>>>>
>>>>
>>>>
>>>>     
>>>>
>>>>> Kathey Marsden wrote:
>>>>>
>>>>>  
>>>>>
>>>>>       
>>>>>
>>>>>> Rick Hillegas wrote:
>>>>>>
>>>>>>            
>>>>>
>>>>
>>>>
>>>>     
>>>>
>>>>>> What happens between September 15 and End of October on the 10.2
>>>>>> branch?
>>>>>>            
>>>>>
>>>>
>>>>
>>>>     
>>>>
>>>>>> If we fix critical bugs during that time in the 10.2 branch can't

>>>>>> they
>>>>>> go into the release end of October?
>>>>>>            
>>>>>
>>>> They should be able to. Since we won't have had a GA release (JCP 
>>>> rules)
>>>> until Mustang ships, it seems any critical bug that we find and fix
>>>> between Sep 15th and Mustang shipping has the potential to require 
>>>> a new
>>>> release candidate and new vote. Could even be a database format 
>>>> change.
>>>>
>>>>
>>>>     
>>>
>>> Let me work out the implications of this.
>>>
>>> o Mustang would ship with a release candidate which the community 
>>> rejected.
>>> o The community would approve a later release candidate and promote it
>>> to GA status.
>>> o Bug reports would come in against both the rejected candidate bundled
>>> into Mustang and the approved candidate which was promoted to GA 
>>> status.
>>>
>>> A couple issues come to mind:
>>>
>>> o In those bug reports, how would we disambiguate the release
>>> candidates? We could bump the last digit of the release identifier 
>>> after
>>> producing the first candidate. Or we could rely on the full version id
>>> produced by sysinfo, which contains the subversion revision number.
>>>   
>>
>>
>> I think we have bumped the fourth version ("point") digit after
>> producing a release candidate. That can be done pretty much at any time,
>> so no issues disambiguating release candidates.
>>
>>  
>>
>>> o The database format change troubles me. What happens if someone
>>> creates a database with the rejected release candidate bundled with
>>> Mustang? I think we want that database to play well with the approved
>>> release candidate which goes GA.
>>>   
>>
>>
>> The mid-Sep Derby release candidate will be marked alpha or beta (JCP
>> rules) so the databases won't upgrade anyway.
>>  
>>
> I apologize for creating confusion here. We'd like Mustang to ship 
> with a fully functional Derby, which creates upgradeable databases. So 
> I'm assuming that we turn off the beta marker on the vetted candidate 
> before handing the candidate to Mustang for QA bake-in.
>
Re-reading your comment, I see another issue which I need to clarify. 
The release candidate is not a GA implementation under the JCP as I 
understand this process. The candidate does not become GA until we post 
it on the Apache mirrors and announce, via the Derby website, that it is 
the latest Derby release.

Mime
View raw message