lucene-java-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Lucene-java Wiki] Update of "ReleaseTodo" by SteveRowe
Date Fri, 25 Jan 2013 06:37: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 SteveRowe:
http://wiki.apache.org/lucene-java/ReleaseTodo?action=diff&rev1=136&rev2=137

  <<TableOfContents>>
  
  = Release Process =
- With the release of Lucene Java 2.2.0 a new release process was established. Prior to every
major release a feature freeze phase takes place for about 1-2 weeks. At the beginning of
the feature freeze the trunk is branched and no commits other than serious bug fixes, documentation
or build updates are permitted. This period of time should be used for extensive testing,
documentation improvements and for cleaning up old JIRA issues.
+ Prior to every major or minor release (i.e. all except bugfix-only point releases) a feature
freeze phase takes place for about 1-2 weeks. At the beginning of the feature freeze the trunk
is branched and no commits other than serious bug fixes, documentation or build updates are
permitted. This period of time should be used for extensive testing, documentation improvements
and for cleaning up old JIRA issues.
  
  = Prerequisites =
-  1. (Optional) Edit your gnupg/gpg.conf file and add a default-key value with your Code
Signing Key (as a HEX value) otherwise you may need to specify -Dgpg.key= later for signing.
 Make sure it is your 4K-bit key and not a 1K-bit key (esp. for ASF old timers)
+  1. (Optional) Edit your gnupg/gpg.conf file and add a default-key value with your Code
Signing Key (as a HEX value) otherwise you may need to specify {{{-Dgpg.key=XXXXXX}}} later
for signing.  Make sure it is your 4K-bit key and not a 1K-bit key (esp. for ASF old timers).
 See http://www.apache.org/dev/release-signing.html for more information.
+  1. You may need to setup people.apache.org as a known host for ssh if you haven't already.
 This happens when you log in manually and follow the prompts.
-  1. If you wish to have the stage target automatically copy the candidates to people.apache.org
(which it does by default unless you specify -Dno.remote.copy=true), you will need the Ant
optional library dependencies (see http://ant.apache.org/manual/install.html#librarydependencies)
for sshexec and scp.  Place them in your ant/lib or $HOME/.ant/lib.
-  1. You may need to setup people.apache.org as a known host for ssh if you haven't already.
  
  = Planning =
- On dev@lucene.apache.org , decide on
+ On dev@lucene.apache.org, decide on
  
   1. which JIRA issues shall be committed before a release is made; set the appropriate "Fix
Version" in JIRA for these issues
   1. the date for branching the trunk and the start of the feature freeze phase
@@ -21, +20 @@

   1. a tentative release date
  
  = Branching & Feature Freeze =
-  1. Run Apache RAT ("ant rat-sources", once you've installed the RAT jars on your CLASSPATH
or ant -lib path) and fix any problems.
-  1. If this is the first release in a series (i.e. release X.Y.0), then create a branch
for the series:
+  1. Run {{{ant precommit}}} to run a bunch of sanity & quality checks, then fix any
problems that are found.
+  1. For the first release in a minor release series - i.e. X.Y.0 - create a minor release
branch off the current major version branch, e.g. for minor release 4.2:
   {{{
- svn copy https://svn.apache.org/repos/asf/lucene/dev/trunk \
+ svn copy https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x \
- https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_X_Y -m "Starting Lucene/Solr
X.Y branch."
+ https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_2 -m "Starting Lucene/Solr
4.2 branch."
  }}}
-  1. After branching the new release series, update the default version in lucene/common-build.xml
on trunk to X.Y+1-SNAPSHOT as well as tests.luceneMatchVersion to X.Y+1. Also update the LUCENE_MAIN_VERSION
in src/java/org/apache/lucene/util/Constants.java. Also add the new enum constant into src/java/org/apache/lucene/util/Version.java.
Update src/test-framework/java/org/apache/lucene/util/LuceneTestCase.java to use the current
version. Update dev-tools/maven/README.maven
+  1. After creating a new release branch, update the version in the base release branch (e.g.
{{{branches/branch_4x}}}):
+     * In {{{solr/CHANGES.txt}}} and {{{lucene/CHANGES.txt}}}, add X.Y+1 release sections
+     * In top-level {{{build.xml}}}
+         * Update property {{{version}}} to X.Y+1-SNAPSHOT
+         * Update property {{{fakeReleaseVersion}}} to X.Y+1
+     * In {{{lucene/common-build.xml}}}:
+         * Update property {{{dev.version}}} to X.Y+1-SNAPSHOT
+         * Update property {{{tests.luceneMatchVersion}}} to X.Y+1-SNAPSHOT
+     * In {{{solr/common-build.xml}}}:
+         * Update property {{{version}}} to X.Y+1-SNAPSHOT
+         * Update property {{{solr.spec.version}}} to X.Y+1.0.${dateversion}
+     * In {{{lucene/core/src/java/org/apache/lucene/util/Constants.java}}}, update {{{LUCENE_MAIN_VERSION}}}
to X.Y+1
+     * In {{{lucene/core/src/java/org/apache/lucene/util/Version.java}}}, add new enum constant
LUCENE_X(Y+1)
+     * Find/replace LUCENE_XY -> LUCENE_X(Y+1) across all of Lucene and Solr
+     * In {{{dev-tools/maven/pom.xml.template}}}:
+         * Update {{{base.specification.version}}} to X.Y+1.0
+         * Update {{{luceneMatchVersion}}} to X.Y+1.0
+     * In {{{dev-tools/idea/.idea/workspace.xml}}}:
+         * Update each mention of {{{lucene.version}}} to X.Y+1-SNAPSHOT
+         * Update each mention of {{{tests.luceneMatchVersion}}} to X.Y+1-SNAPSHOT
+ 
+  1. If the X.Y default index format is different from the X.Y-1 default index format, add
a X.Y-1 index to {{{lucene/dev/branches/branch_4x/lucene/core/src/test/org/apache/lucene/index/TestBackwardsCompatibility.java}}}
- see the comments there for instructions.
-  1. If it is a new major version, also update IndexFormatTooOldException to have the correct
minimum version string.
+  1. If it is a new major version, also update {{{IndexFormatTooOldException}}} to have the
correct minimum version string.
-  1. Prepare the backwards-compatibility tests in trunk (only if a new major release was
started and you created the branch before):
-  {{{
- svn rm backwards/src/
- svn cp https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_X_Y/lucene/src/
backwards/src/
- ant test-backwards
- }}}
   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.
+   * 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.
+   * All patches that are intended for the branch should first be committed to trunk, merged
into the minor release branch, and then into the current release 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.
+   * Normal trunk and minor release branch 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.
+   * '''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 https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_X_Y}}}
-  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 [[https://issues.apache.org/jira/browse/LUCENE-2285?focusedCommentId=12839224&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12839224|https://issues.apache.org/jira/browse/LUCENE-2285?focusedCommentId=12839224&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12839224]]
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
@@ -53, +66 @@

   1. Call a release vote on dev@ and cc general@lucene.apache.org .
  
  = 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)
  
+ 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. Option 1: use {{{dev-tools/scripts/buildAndPushRelease.py}}} to build a release candidate,
and optionally push the results to {{{people.apache.org}}}, and optionally run {{{dev-tools/scripts/smokeTestRelease.py}}}
on it.  Read the instructions in comments at the top of {{{buildAndPushRelease.py}}}.
+  1. Option 2: manually build a release candidate:
+     a. Verify that {{{svnversion}}} reports a single revision with no modified changes
+     a. Remove {{{contrib/benchmark/{work,temp}}}} if present
+     a. 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)
+     a. Sanity check the overall size of each artifact. EG, compare to the last release.
+     a. Make sure that for each release file an md5 checksum file exists.
+     a. {{{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)
+ 
- == Example for 3.1 ==
+  Example for 3.1:
- {{{
+     {{{
-      >ANT_OPTS="-Xmx256m -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=128M" ant -Dversion=3.1.0
-Dgpg.key=FE045966 prepare-release
+      PROMPT$ ANT_OPTS="-Xmx256m -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=128M" ant
-Dversion=3.1.0 -Dgpg.key=FE045966 prepare-release
-      // Inspect the artifacts
+      # Inspect the artifacts
-      >ant -Dversion=3.1.0 -Drc=rc3 -Dscp.user=gsingers copy-to-stage
+      PROMPT$ ant -Dversion=3.1.0 -Drc=rc3 -Dscp.user=gsingers copy-to-stage
  }}}
  
  = Testing the Release artifacts =
-  1. There is a script in SVN to do automated checks on a release candidate, e.g {{{python
dev-tools/scripts/smokeTestRelease.py http://people.apache.org/~whoever/3.7.0rc1 3.7.0 tmp}}}

+  1. There is a script in SVN to do automated checks on a release candidate, e.g {{{python3.2
-u dev-tools/scripts/smokeTestRelease.py http://people.apache.org/~whoever/3.7.0rc1-rev1384901
3.7.0 tmp}}} 
  
  = Publishing =
  Once [[http://www.apache.org/foundation/voting.html#ReleaseVotes|three PMC members have
voted for a release]], it may be published.
@@ -79, +96 @@

  svn copy https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_X_Y \
  https://svn.apache.org/repos/asf/lucene/java/tags/lucene_solr_X_Y_Z -m "Lucene Java X.Y.Z
release."
  }}}
-  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 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 [[http://jakarta.apache.org/site/convert-to-mirror.html?Step-By-Step|Guide To Distributing
Existing Releases Through The ASF Mirrors]] and the links that are there.
-  1. Copy the KEYS file (from http://people.apache.org/keys/group/lucene.asc), and the non-Maven
release artifacts to the dist directory {{{people.apache.org:/www/www.apache.org/dist/lucene/java}}},
and remove the old files
-  1. Make sure the group ownership on the site is 'lucene' by calling {{{chgrp -R lucene
/www/www.apache.org/dist/lucene/java}}}. Also make files group writable and others read-only
by calling {{{chmod -R g+w,o-w /www/www.apache.org/dist/lucene/java}}}
   1. [[PublishMavenArtifacts|Publish Maven Artifacts]]
+  1. Wait 24 hours to give the mirrors a chance to get the new release.  There is a script
that will continually check the number of mirrors (and Maven Central) that have the release
for you: {{{dev-tools/scripts/poll-mirrors.pl}}}.
-  1. Checkout https://svn.apache.org/repos/asf/lucene/dev/nightly and update VERSION=X.Y-$BUILD_ID
in all the shell files. See http://wiki.apache.org/general/Jenkins 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.
  
  = Pushing website changes & Announcing =
  

Mime
View raw message