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/%
[EMAIL PROTECTED]
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
