db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "DerbySnapshotOrRelease" by AndrewMcIntyre
Date Fri, 14 Oct 2005 04:28:16 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by AndrewMcIntyre:

   Also, a new JIRA version will need to be created for the new, bumped version number. An
email to derby-dev stating that you've bumped the version will (hopefully) be sufficient to
get the attention of one of the Derby JIRA admins to add a new version in JIRA.
-  1. Announce your intention to have a release on the list
+  1. Announce your intention/desire to have a release on the list
-  1. Volunteer (or enlist) a release manager
-  1. Make sure that an entry for the release version exists in JIRA
+   As new features are added and bugs fixed, it is likely that someone will announce their
intention to produce a release (if they are a committer) and volunteer to be the release manager.
It may also be the case that a non-committer will ask when the next official release will
occur. This should be a sign to committers that there is demand for a release. :)
+  1. Volunteer as release manager (or try to enlist one)
+   Since only committers have the necessary access to Apache resources to shephard a release
to its completion, a committer must volunteer to be the release manager. Usually (hopefully)
someone will volunteer if it is clear there is demand for a release. A release manager is
under no obligation to finish once they volunteer, and another committer can pick up and complete
their work, or even produce a competing release if so desired.
-  1. For a bug fix release, target the bugs you feel should be fixed in JIRA
+  1. Target the bugs you feel should be fixed in JIRA
+   All features and bug fixes should be tracked in JIRA: http://issues.apache.org/jira/browse/DERBY
+   Mark the Fix In field for the JIRA entries for the items you want to be in the release
with the proper version. Also, it's a good idea to post to derby-dev to get an idea of what
features or fixes other contributors would like in the release.
   1. Fix the bugs, update STATUS and CHANGES as needed
+   Get to work! Add features, fix bugs, and update STATUS and CHANGES as you go. The wiki
is nice, as are personal webpages, but STATUS and CHANGES are the designated place for Apache
projects to keep their current status. Apache members and committers expect to be able to
grab the STATUS file from the code tree to determine the current status of the project. It's
a nice thing to keep the STATUS file on branches up to date with the current status of the
+  1. Drive the bug list to zero.
+   As the list of remaining bugs in JIRA approaches zero, be sure to mark their status properly
in JIRA. Mark blocker and critical bugs as such so that others can see the status at a glance.
Move non-showstopper bugs out to future releases if it appears they will not be fixed for
this release.
   1. Create the release distributions and checksums, sign the distributions
-   a. Put your key in KEYS if you haven't done so. 
-   b. Verify checksums/signatures
+   Once the bug list hits zero, create the distributions for release. Check that the settings
in tools/ant/properties/packaging.properties are correct for your md5 hash tool and pgp/gpg
tool and then run:
+   {{{svn up
+ ant clobber
+ ant -Dsane=false snapshot
+ cd plugins/
+ cd tools/release
+ ant release}}}
+   You will need to enter your PGP passphrase several times as the release distributions
are signed. This will create the following files in your tools/release directory:
+   db-derby-[version]-bin.tar.gz
+   db-derby-[version]-bin.zip
+   db-derby-[version]-lib.tar.gz
+   db-derby-[version]-lib.zip
+   db-derby-[version]-src.tar.gz
+   db-derby-[version]-src.zip
+   The Eclipse core plugin is generated in the snapshot directory at the top level by the
snapshot target. You should also create the Eclipse UI plugins (see plugins/eclipse/readme.txt),
but this requires Eclipse. If you don't want to do it yourself, those interested in the Eclipse
plugins will likely volunteer to generate them for you. You should also create checksums and
signatures for these files with:
+   {{{gpg --armor --detach-sign derby_ui_plugin_[version].zip
+ gpg --armor --detach-sign derby_core_plugin_[version].zip
+ md5 -q derby_ui_plugin_[version].zip > derby_ui_plugin_[version].md5
+ md5 -q derby_core_plugin_[version].zip > derby_core_plugin_[version].md5}}}
+  1. Verify the signatures and checksums.
+   As an example, the Derby 10.1 archives would be verified with PGP as follows:
+   {{{gpg --verify derby_ui_plugin_1.1.0.zip.asc derby_ui_plugin_1.1.0.zip
+ gpg --verify derby_core_plugin_10.1.1.zip.asc derby_core_plugin_10.1.1.zip
+ gpg --verify db-derby- db-derby-
+ gpg --verify db-derby- db-derby-
+ gpg --verify db-derby- db-derby-
+ gpg --verify db-derby- db-derby-
+ gpg --verify db-derby- db-derby-
+ gpg --verify db-derby- db-derby-}}}
+   The md5 checksums can be verified by generating them via another method. For example,
using openssl:
+   openssl md5 < db-derby-
+   And comparing the output of openssl to the output from ant in db-derby-
+  1. Make sure your public PGP key is in the KEYS file.
+   Also, make sure that it is uploaded to at least one, and preferably two, of the public
keyservers, such as pgp.mit.edu.
   1. Post the distributions
+   Copy the files from tools/release to your public_html directory on minotaur.apache.org.
Post to derby-dev so that others can begin testing.
   1. Vote on the distributions
+   Call for a vote on derby-dev to have the distributions posted on your public_html accepted
for the release. It is a good idea to wait at least a week before closing the vote to give
adequate time for others to inspect and test the distributions. If no-one has responded after
a week, prod gently until you get a response. A majority of votes, and at least one binding
+1 vote are required for acceptance.
   1. Put distributions onto mirrors
-   a. link -current to new files, move old files to archive
+   First, read:
+   http://www.apache.org/dev/mirrors.html and
+   http://www.apache.org/dev/mirror-step-by-step.html
+   Copy the distribution archives and their signatures/checksums to a new directory underneath
/www/www.apache.org/dist/db/derby on minotaur.apache.org. If the new release is the most current
feature release, link the -current links to the new files. If this release supercedes a previous
release on a branch, be sure to move the old files to the archive. It is important that we
keep our mirror directory tidy.
+   You should also make sure that your public PGP key is in the KEYS file at /www/www.apache.org/dist/db/derby/KEYS
   1. Create a page for the release, build/update site
-  1. Make everyone happy - create Eclipse plugins, deploy to Maven repository
-  1. Announce
-  1. Update STATUS again
-  1. Bump the version number to next version
+   For instructions on how to build the website, see item 3 regarding snapshots above. It
is a good idea to use the previous release pages as templates, filling in the changed details
as necessary. You should add a .cgi and a .html file for the release. The main thing to remember
is that the .cgi file should have the same name as the .html file. Also, when you run 'svn
up' on minotaur.apache.org (3e above), make sure that the new .cgi file is executable and
otherwise has the correct permissions!
+  1. Deploy to Maven repository.
+   From Jeremy Boynes:
+   To run this build, cd into maven and
+    $ maven  # will attain the multiproject:install goal to install the artifacts into your
local maven repo
+    $ maven clean  # will attain the multiproject:clean goal to clean up the maven tree
+    $ maven multiproject:deploy  # will copy all the artifacts into the apachecvs repository
(note, for now this this has been disabled by commenting out the maven.repo.list definition
in project.properties).
+   This does not build using maven, it works by copying the jars that ant built into jars/${sanity}
+  1. Announce the release.
+   Twenty-four hours after putting the release files in the mirror directory, verify that
you can reach them through a mirror. Then, you should email derby-dev, derby-user, general@db.apache.org,
announce@apache.org and anyone else you think might be interested an announcement concerning
the release. See past release announcements for examples.
+   Include a description of the project, and a description of any significant new features
or important bug fixes. Every tech news blog remotely related to Java or databases will pick
up the announcement and post it verbatim, so it's a good idea to spell check it, proofread
it a couple of times, and/or get input from other committers on its content.
+  1. Bump the version number to next version.
+   For a bugfix release, follow steps 4 and 5 in the snapshot section. There is not currently
a target for bumping the version number for a feature release. You should edit release.properties
by hand, and then, from the top, run:
+   {{{java maintversion2props tools/ant/properties/release.properties tools/release/maintversion.properties
+ ant regex.masters}}}
+   Don't forget to post to derby-dev requesting that a new version be added to JIRA for the
next version of Derby.
+  1. Update STATUS again.
+   Update STATUS to reflect that the release has occurred. Check in the new file. You're

View raw message