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:43:39 GMT
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.

>Dan.
>
>
>  
>


Mime
View raw message