db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew McIntyre <mcintyr...@gmail.com>
Subject Re: 10.1 release candidate jars
Date Thu, 16 Jun 2005 18:22:30 GMT

On Jun 15, 2005, at 9:40 AM, Daniel John Debrunner wrote:

> Marking this jars not alpha/beta defeats the whole purpose of the
> versioning scheme, which is to ensure that pre-release software  
> does not
> get used in production environments. A development flag was added to
> allow testing of upgrade of pre release jars.

I have put the beta flag back and updated the files on my public_html  
page. I had only removed it to facilitate upgrade testing, and was  
hesitant to do it even then. I was unaware of the  
allowPreReleaseUpgrade flag, having missed the original discussions,  
as others may have. For reference:

http://mail-archives.apache.org/mod_mbox/db-derby-dev/200505.mbox/% 
3c42796424.6020208@debrunners.com%3e

and the short version being that upgrade from a previous version of  
Derby may be tested by setting the system property  
derby.database.allowPreReleaseUpgrade=true.

maybe now would be a good time to describe the flag to the list?

> This would be a good time to remind people how the release process
> works, in terms of testing, voting and what a vote means. We have a  
> lot
> of new developers on the list since the last Derby release.

Sure.

First, I'd like to point anyone unfamiliar with the Apache release  
process to the excellent pages on releases for both Jakarta Commons  
and httpd:

http://httpd.apache.org/dev/release.html
http://jakarta.apache.org/commons/releases/

While there is a fair amount of information specific to those  
projects, they apply generally to how Derby releases should be  
handled as well. Of specific interest is the section "Who can vote?"  
on the httpd page and the voting section of the Jakarta 'Preparing  
for a release' page. By the Jakarta path, we're still in the 'Resolve  
Bugs' phase of this release.

It should be clear from those documents that it is very important  
that release candidates are well tested by the community. People who  
have submitted features and fixes should test that their contribution  
is working properly in the release candidate. It would also be  
helpful if people tested each other's features and fixes to have a  
fresh pair of eyes on them. At the very least, anyone with some time  
should at least run derbyall against the release candidate jars on  
their platforms of interest to turn up any possible platform-specific  
issues.

When the release is put up for a vote, anyone who has tested the  
release candidate should post to the list with their vote of approval  
or disapproval of the release candidate. There are no vetos in a  
release vote, and a release candidate with a majority of postive  
votes should be released.

Are there any other particulars related to testing/voting that you  
feel should be emphasized, Dan?

andrew

Mime
View raw message