lucene-java-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Lucene-java Wiki] Update of "ReleaseTodo" by GrantIngersoll
Date Fri, 25 Mar 2011 17:17:25 GMT
Dear Wiki user,

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

The "ReleaseTodo" page has been changed by GrantIngersoll.


    * Normal trunk development may continue as usual. However, if you plan to commit a big
change to the trunk while the branch feature freeze is in effect, think twice: can't the addition
wait a couple more days? Merges of bug fixes into the branch may become more difficult.
    * *Only* Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release
candidate build.
- = Staging Area and Release Candidates =
+ = Release Workflow =
   1. Check out the branch with: {{{svn co}}}
   1. Add an entry for the new version in the doap.rdf file, stored under docs/doap.rdf in
the unversioned site (see
   1. If the release is < 3.0, ensure "ant test-core" passes in a 1.4 Java environment.
Important: Do two tests: Compile & test with Java 1.4, but also compile with Java 5 and
only run tests with 1.4. This ensures, that the artifacts are really working with Java 1.4
(see the comment [[|]]
for explanation).
   1. Build the code and javadocs, and run the unit tests: ant clean javadocs test
   1. Examine the results. Did it build without errors? Were there Javadoc warnings? Did the
tests succeed? Does the demo application work correctly? Does Test2BTerms pass?
   1. Remove contrib/benchmark/{work,temp} if present
+  1. Build as defined below in the "Building the Release Artifacts" section.
-  1. Package the release with a command like: {{{ant -Dversion=2.3.0-rc1 -Dspec.version=2.3.0
clean dist-all generate-maven-artifacts}}}. Make sure it finishes successfully.
-  1. Generate Changes.html by running {{{ant changes-to-html}}}, then open build/docs/changes/Changes.html
with a browser and confirm it looks right.
   1. Create a staging area on your public Apache website
@@ -61, +60 @@

     scp -r build/docs/changes
   1. If during the feature freeze phase bug fixes are committed to the X.Y branch then build
another release candidate and announce on dev@ and java-user@ that everyone should use the
new RC for testing.
+  1. Call a release vote on java-dev and cc .
  = Building the Release artifacts =
   1. If after the last day of the feature freeze phase no blocking issues are in JIRA with
"Fix Version" X.Y then it's time to build the release artifacts
   1. Verify that "svnversion" reports a single revision with no modified changes
   1. Remove contrib/benchmark/{work,temp} if present
-  1. Build the release artifacts: {{{ant -Dversion=2.3.0 clean dist-all generate-maven-artifacts}}}
+  1. Build the release artifacts: {{{ant -Dversion=2.3.0 }}}-Dgpg.exe=/path/to/gpg -Dgpg.key=YourKeyID
-Dgpg.passphrase=YourPassPhrase{{{ clean stage}}}
   1. Sanity check the overall size of each artifact. EG, compare to the last release.
   1. Make sure that for each release file an md5 checksum file exists.
-  1. Sign the release (see [[|Step-By-Step
Guide to Mirroring Releases]] for more information). Also sign all Maven release artifacts.
-  {{{
- gpg --armor --output lucene-X.Y.Z.tar.gz.asc --detach-sig lucene-X.Y.Z.tar.gz
- }}}
-  Since Lucene 3.1 a special ANT task is available for signing: "ant sign-artifacts -Dgpg.exe=/path/to/gpg
-Dgpg.key=YourKeyID -Dgpg.passphrase=YourPassPhrase". If you do not supply a passphrase, you
are asked for it. The default key ID is "CODE SIGNING KEY".
-  1. Copy release files to the staging area: {{{scp -r dist}}}
-  1. Copy the KEYS file into the same directory.
-  1. Call a release vote on java-dev and cc .
  = Publishing =
  Once [[|three PMC members have
voted for a release]], it may be published.

View raw message