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 Sun, 13 Mar 2011 07:30:31 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.
The comment on this change is: java-dev@ -> dev@; lucene_X_Y(_Z) branch (tag) -> lucene_solr_X_Y(_Z)
branch (tag); changes2html.pl doesn't need the release date; nightly script info fixed.
http://wiki.apache.org/lucene-java/ReleaseTodo?action=diff&rev1=82&rev2=83

--------------------------------------------------

  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.
  
  = Planning =
- On java-dev, 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
@@ -18, +18 @@

   1. If this is the first release in a series (i.e. release X.Y.0), then create a branch
for the series:
   {{{
  svn copy https://svn.apache.org/repos/asf/lucene/dev/trunk \
- https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_X_Y -m "Starting Lucene X.Y
branch."
+ https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_X_Y -m "Starting Lucene/Solr
X.Y branch."
  }}}
-  1. After branching the new release series, update the default version in common-build.xml
on trunk to X.Y+1-dev and the default version in common-build.xml on the branch to X.Y (remove
the -dev suffix). 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/org/apache/lucene/util/LuceneTestCase.java
to use the current version.
+  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/Constants.java.
Also add the new enum constant into src/java/org/apache/lucene/util/Version.java. Update src/test/org/apache/lucene/util/LuceneTestCase.java
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):
   {{{
  svn rm backwards/src/
- svn cp https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_X_Y/lucene/src/ 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. Update CHANGES.txt and contrib/CHANGES.txt in trunk and the branch. Specify tentative
release date and start a new section for X.Y+1-dev in the trunk's CHANGES.txt.
   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 (http://wiki.apache.org/lucene-java/HowToUpdateTheWebsite)
and commit.
   1. On the branch, fix the same files, rebuild the website and commit.
-  1. Send a note to java-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:
+  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.
@@ -38, +38 @@

    * *Only* Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release
candidate build.
  
  = Staging Area and Release Candidates =
-  1. Check out the branch with: {{{svn co https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_X_Y}}}
+  1. Check out the branch with: {{{svn co https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_X_Y}}}
   1. Add an entry for the new version in the doap.rdf file, stored under docs/doap.rdf in
the unversioned site (see http://wiki.apache.org/lucene-java/HowToUpdateTheWebsite).
   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. In preparation for the next step, download the Maven ant tasks JAR (eg maven-ant-tasks-2.0.9.jar)
from http://maven.apache.org/download.html, and add into your CLASSPATH, or add "-lib XXX.jar"
to the ant command in the next step
+  1. In preparation for the next step, download the Maven ant tasks JAR (maven-ant-tasks-2.1.1.jar)
from http://maven.apache.org/download.html, and add into your $HOME/.ant/lib/ directory, or
CLASSPATH, or add "-lib XXX.jar" to the ant command in the next step
   1. Remove contrib/benchmark/{work,temp} if present
   1. Package the release with a command like: {{{ant -Dversion=2.3.0-rc1 -Dspec.version=2.3.0
clean dist dist-src 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.
@@ -52, +52 @@

     ssh people.apache.org
     mkdir public_html/staging-area
  }}}
-  1. Copy the release candidate and changes.html to the staging area and announce on java-dev
and java-user that it is available for testing. Make sure your directory permissions disallow
writing ({{{chmod -R a-w public_html/staging-area/*}}}, after copying).
+  1. Copy the release candidate and Changes.html to the staging area and announce on dev@
and java-user@ that it is available for testing. Make sure your directory permissions disallow
writing ({{{chmod -R a-w public_html/staging-area/*}}}, after copying).
   {{{
     ssh people.apache.org
     mkdir public_html/staging-area/rc1
     scp -r dist people.apache.org:public_html/staging-area/luceneX.Yrc1
     scp -r build/docs/changes people.apache.org:public_html/staging-area/luceneX.Ychanges
  }}}
-  1. If during the feature freeze phase bug fixes are committed to the X.Y branch then build
another release candidate and announce on java-dev and java-user that everyone should use
the new RC for testing.
+  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.
  
  = 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. Guestimate the release date and update CHANGES.txt on the branch and commit it
-  1. Update src/site/changes/changes2html.pl (in setup_release_dates) with the date, and
commit it to trunk and branch
   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 dist-src generate-maven-artifacts}}}
@@ -74, +73 @@

   {{{
  gpg --armor --output lucene-X.Y.Z.tar.gz.asc --detach-sig lucene-X.Y.Z.tar.gz
  }}}
-  Since Lucene 3.1 as 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".
+  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 people.apache.org:public_html/staging-area/luceneX.Y}}}
   1. Copy the KEYS file into the same directory.
   1. Call a release vote on java-dev and cc general@lucene.apache.org .
@@ -84, +83 @@

  
   1. Tag the release:
   {{{
- svn copy https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_X_Y \
+ 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_X_Y_Z -m "Lucene Java X.Y.Z release."
+ 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 your first release, add your key to the KEYS file. The KEYS file is located
in Subversion at [WWW] https://svn.apache.org/repos/asf/lucene/java/dist and copy it to the
release directory. Make sure you commit your change.
@@ -95, +94 @@

   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. Copy the Maven artifacts to the distribution directory (follow the existing directory
structure), to have them pushed to the central Maven repositories: {{{people.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/lucene}}}
   1. Make sure the group ownership on the site is 'lucene' by calling {{{chgrp -R lucene
/www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/lucene}}}. Also make files
group writable and others read-only by calling {{{chmod -R g+w,o-w /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/lucene}}}
-  1. Checkout https://svn.apache.org/repos/asf/lucene/java/nightly and change the -Dversion=X.Y-SNAPSHOT
in nightly.sh. Also configure the Hudson script (http://hudson.zones.apache.org/hudson/job/Lucene-trunk/configure)
and set the -Dversion=X.Y-SNAPSHOT value in the "execute shell" section. Save this change.
See http://wiki.apache.org/general/Hudson for how to get a login on hudson, or ask Grant or
Michael B. for help.
+  1. Checkout https://svn.apache.org/repos/asf/lucene/java/nightly and update VERSION=X.Y-$BUILD_ID
in hudson-lucene-X.x.sh . See http://wiki.apache.org/general/Hudson 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 =

Mime
View raw message