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 Sat, 26 Mar 2011 11:44:09 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.

-------------------------------------------------- -m "Starting Lucene/Solr
X.Y branch."
   1. After branching the new release series, update the default version in lucene/common-build.xml
on trunk to X.Y+1-dev and the default version in lucene/common-build.xml on the branch to
X.Y (remove the -SNAPSHOT suffix). Also update the LUCENE_MAIN_VERSION in src/java/org/apache/lucene/util/
Also add the new enum constant into src/java/org/apache/lucene/util/ Update src/test/org/apache/lucene/util/
to use the current version.
-  1. Prepare the backwards-compatibility tests in trunk (only if a new major release was
started and you created the branch before):
+  1. Prepare the backwards-compatibility tests in trunk (only if a new major release was
started a
-  {{{
- svn rm backwards/src/
- svn cp
- ant test-backwards
- }}}
-  1. On trunk, fix src/site/src/documentation/content/xdocs/{tabs.xml,index.xml} to reference
the X.Y+1-dev version. Rebuild the website (
and commit.
-  1. On the branch, fix the same files, rebuild the website and commit.
-  1. Send a note to dev@ to inform the committers that the branch has been created and the
feature freeze phase has started. Include Do's and Don'ts for the feature freeze phase:
-   * No new features may be committed to the branch.
-   * Documentation patches, build patches and serious bug fixes may be committed to the branch.
However, you should submit *all* patches you want to commit to Jira first to give others the
chance to review and possibly vote against the patch. Keep in mind that it is our main intention
to keep the branch as stable as possible.
-   * All patches that are intended for the branch should first be committed to trunk and
then merged into the branch.
-   * 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.
- = 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. 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=X.Y.Z }}}[-Dgpg.exe=/path/to/gpg -Dgpg.key=YourKeyID
-Dgpg.passphrase=YourPassPhrase{{{] prepare-release  //Items in [] may be optional}}}
-  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. ant -Dversion=X.Y.Z copy-to-stage to move the artifacts up to the staging area (see
the build target for all the options for securly copying the artifacts up)
- = Publishing =
- Once [[|three PMC members have
voted for a release]], it may be published.
-  1. Tag the release:
-  {{{
- svn copy \
- -m "Lucene Java X.Y.Z
- }}}
-  1. If this is a new branch (ie you are releasing X.Y.0), after tagging, commit a new "unreleased"
section at the top of CHANGES.txt and contrib/CHANGES.txt onto the branch
-  1. If this is your first release, add your key to the KEYS file. The KEYS file is located
in Subversion at [WWW] and copy it to the
release directory. Make sure you commit your change.
-  1. If this is a point release, copy the CHANGES.txt entry for this point release back to
the trunk's CHANGES.txt. Remove any duplicate entries from trunk's CHANGES.txt (ie, each issue
should appear only once, in the earliest point-release that contains the fix, on the assumption
that all future releases also contain the fix).
-  1. See [[|Guide To Distributing
Existing Releases Through The ASF Mirrors]] and the links that are there.
-  1. Copy the KEYS file, and the non-Maven release artifacts to the dist directory {{{}}},
and remove the old files
-  1. Make sure the group ownership on the site is 'lucene' by calling {{{chgrp -R lucene
/www/}}}. Also make files group writable and others read-only
by calling {{{chmod -R g+w,o-w /www/}}}
-  1. Copy the Maven artifacts to the distribution directory (follow the existing directory
structure), to have them pushed to the central Maven repositories: {{{}}}
-  1. Make sure the group ownership on the site is 'lucene' by calling {{{chgrp -R lucene
/www/}}}. Also make files
group writable and others read-only by calling {{{chmod -R g+w,o-w /www/}}}
-  1. Checkout and update VERSION=X.Y-$BUILD_ID
in . See for how to get a login
on Jenkins (formerly Hudson), or ask Grant or Michael B. for help.
-  1. Wait 24 hours to give the mirrors a chance to get the new release.
- = Announcing =
-  1. Checkout the top-level Lucene website from
Add a new item under "News", in index.xml. Run "forrest site", confirm all looks good, then
recursively copy build/site/* to publish/*, then commit the changes. Then copy publish/* to
/www/* on Be sure to change the group and attributes
of the copied files: {{{cd /www/; chown lucene * images/* skin/*; chmod
g+w,o-w * images/* skin/*}}}.
-  1. Checkout the Lucene java website from
Add a new item under "Lucene News", in index.xml. Add a new entry for this release into both
tabs.xml and site.xml. Run "forrest site", confirm all looks good, and recursively copy build/site/*
to docs/*, then commit the changes. Copy docs/* to /www/ on
Make sure .htaccess is copied!
-  1. Copy the release specific docs to
-  {{{
-   ssh
-   tar xzf lucene-X.Y.Z.tar.gz lucene-X.Y.Z/docs
-   mv lucene-X.Y.Z/docs /www/
-   rmdir lucene-X.Y.Z
- }}}
-  1. Make sure the group ownership on the site is 'lucene' by calling {{{chgrp -R lucene
/www/}}}. Also make files group writable and others read-only by calling
{{{chmod -R g+w,o-w /www/}}}.
-  1. Wait for these changes to appear on Apache's main webserver (
before doing the next steps (see for details on
how the site is mirrored to Apache's main web servers). Once they appear, verify all links
are correct in your changes!
-  1. Add the new version to Wikipedia (english and maybe your own language)
-  1. Announce the release on , ,
and mailing lists. A draft should be sent to the development list first
to clarify any possible issues in the announcement. Mails to the announce list should be sent
from an email address and contain a signature.
-  1. Ensure the latest Lucene Jar + MD5 sum file have been pushed to
by deploying the distribution to
(that is From
there it will be pushed to the central Maven repositories (both Maven 1 and Maven 2) automatically
in a few hours. Contact if there's some problem.
-  1. Go to the JIRA "Manage Versions" Administration page (
and click Release for the version you just released. Also add a new (unreleased) version for
the next release on the trunk (for a major release) or branch (for a minor release).
-  1. Go to JIRA and find all issues that were fixed in the release you just made, whose Status
is Resolved, and do a bulk change to close all of these issues. Uncheck the box that says
"send an email for these changes".
- = See Also =
-  * [[|Apache Releases FAQ]]

View raw message