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 MichaelBusch
Date Fri, 18 Jan 2008 23:22:58 GMT
Dear Wiki user,

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

The following page has been changed by MichaelBusch:
http://wiki.apache.org/lucene-java/ReleaseTodo

------------------------------------------------------------------------------
- Things that should be done when a new release is made:
+ ''Note: You need committer rights to create a new Lucene release.''
  
- 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.
+ = Release Process =
  
- 2. Announce the release on [http://www.freshmeat.net]
+ 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.
  
- 3. Ensure the latest Lucene Jar + MD5 sum file have been pushed to http://repo1.maven.org/maven2/org/apache/lucene/
by deploying the distribution to http://people.apache.org/repo/m2-ibiblio-rsync-repository/
(that is minotaur.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository).  From
there it will be pushed to the central Maven repositories (both Maven 1 and Maven 2) automatically
in a few hours. Contact repository@apache.org if there's some problem.
+ = Planning =
  
- 4. Go to the JIRA "Manage Versions" Administration page (http://issues.apache.org/jira/secure/project/ManageVersions.jspa?pid=12310110)
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).
+ On java-dev, 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
+    1. the length of the feature freeze phase
+    1. a tentative release date
  
- 5. 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".
+ = Branching & Feature Freeze =
  
- --------------
+    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/java/trunk \
+ https://svn.apache.org/repos/asf/lucene/java/branches/branch-X.Y -m "Starting Lucene 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.
+    1. Update 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. 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:
+       * 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. 
+    
+ = Staging Area and Release Candidates =
  
- How to make a release:(see also: http://wiki.apache.org/lucene-hadoop/HowToRelease)
-  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/java/trunk \}}} 			{{{https://svn.apache.org/repos/asf/lucene/java/branches/branch-X.Y
-m "Starting Lucene X.Y branch." }}}	
-  1. Check out the branch with: 		{{{svn co https://svn.apache.org/repos/asf/lucene/java/branches/branch-X.Y
\}}}
+    1. Check out the branch with: {{{svn co https://svn.apache.org/repos/asf/lucene/java/branches/branch-X.Y}}}
-  1. Build the code and javadocs, and run the unit tests: {{{ant clean javadocs test}}}
+    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?
+    1. Examine the results. Did it build without errors? Were there Javadoc warnings? Did
the tests succeed?
-  1. Package the release with a command like:
-    {{{ant -Dversion=1.9-rc1 clean dist dist-src}}} (The version here should be formatted
as in default.properties.)
-  1. Examine the results.  Did it build without errors?  Unpack the release somewhere, examine
the files, run some simple tests.  Do not proceed further until you are confident that this
release is of appropriate quality.
-  1. Update the CHANGES.txt file. Check the email archives, and make sure that there is an
entry in this file for every significant CVS commit message.
-  1. Commit CHANGES.txt changes and the docs.
-  1. Tag the files in SVN with the release name.
- {{{svn copy https://svn.apache.org/repos/asf/lucene/java/branches/branch-X.Y \}}} 			{{{https://svn.apache.org/repos/asf/lucene/hadoop/tags/release-X.Y.Z
-m "Lucene X.Y.Z release." }}}
-  1. Sign and create md5 sums for each release file.
-  1. Copy the files to the release directory  
-   {{{people.apache.org:/www/www.apache.org/dist/lucene/java}}}
-  1. Copy the Jar and MD5 sum files 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. 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}}} 
+    1. Create a staging area on your public Apache website {{{
+    ssh people.apache.org 
+    mkdir public_html/staging-area}}}
+    1. Copy the release candidate to the staging area and announce on java-dev and java-user
that it is available for testing.{{{
+    ssh people.apache.org 
+    mkdir public_html/staging-area/rc1 
+    scp -r dist/* people.apache.org:public_html/staging-area/rc1}}}
+    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.
+    
+ = 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 build the release artifacts: {{{ant -Dversion=2.3.0 clean dist dist-src
generate-maven-artifacts}}}
+    1. Make sure that for each release file an md5 checksum file exists.
+    1. Sign the release (see [http://www.apache.org/dev/mirror-step-by-step.html?Step-By-Step
Step-By-Step Guide to Mirroring Releases] for more information). {{{
+ gpg --armor --output lucene-X.Y.Z.tar.gz.asc --detach-sig lucene-X.Y.Z.tar.gz
+ }}}
+    1. Copy release files to the staging area: {{{scp -r dist/* people.apache.org:public_html/staging-area}}}
+    1. Call a release vote on java-dev.
+ 
+ = Publishing =
+ 
+ Once [http://www.apache.org/foundation/voting.html#ReleaseVotes three PMC members have voted
for a release], it may be published.
+    1. Update the doap file for projects.apache.org
+    1. Tag the release: {{{
+ svn copy https://svn.apache.org/repos/asf/lucene/java/branches/branch-X.Y \
+ https://svn.apache.org/repos/asf/lucene/java/tags/release-X.Y.Z -m "Lucene Java X.Y.Z release."
+ }}}
-  1. If this is your first release, add your key to the KEYS file.  The KEYS file is located
in Subversion at https://svn.apache.org/repos/asf/lucene/java/dist and copy it to the release
directory.  Make sure you commit your change.
+    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.
+    1. Copy the files to the release directory {{{people.apache.org:/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. Wait 24 hours to give the mirrors a chance to get the new release.
+    1. Wait 24 hours to give the mirrors a chance to get the new release.
-  1. Update the website (See http://wiki.apache.org/solr/Website_Update_HOWTO for Solr's
guide to using Forrest)
+    1. Update the website (See http://wiki.apache.org/solr/Website_Update_HOWTO for Solr's
guide to using Forrest) {{{
-   {{{
    ssh www.apache.org
    cd /www/lucene.apache.org/java
  
-   mkdir MAJOR_MINOR_BUILD directory where MAJOR, MINOR, BUILD correspond to the version,
e.g. 2_0_0 contains the 2.0.0 release site.  See the existing structure in the directory if
you have any questions
+   mkdir MAJOR_MINOR_BUILD directory where MAJOR, MINOR, BUILD correspond to the version,
e.g. 2_3_0 contains the 2.3.0 release site.  See the existing structure in the directory if
you have any questions
  
    Copy the release docs dir into this dir (make sure you do a recursive copy)
  
-   Add a new link to the "Site Versions" section of the docs (site.xml in src/site/documentation/content/xdocs)
similar to the existing links.  This change will be automatically synched with the main website
via the nightly build.
+   Add a new link to the "Documentation" section of the main website (site.xml and tabs.xml
in https://svn.apache.org/repos/asf/lucene/java/site/src/documentation/content/xdocs) similar
to the existing links.  This change will be automatically synched with the main website via
the nightly build.
  }}}
+    1. Update the javadoc on the website under the directory version you have created in
12. This is done by unpacking it from the release that you've just made, moving it into place.
{{{
-  1. Update the javadoc on the website under the directory version you have created in 12.
-  This is done by unpacking it from the release that you've just made, moving it into place.
{{{
    ssh www.apache.org
  
    cd /www/lucene.apache.org/java/MAJOR_MINOR_BUILD (see 12)
  
-   tar xzf ../../builds/jakarta-lucene/release/v1.9-rc1/lucene-1.9-rc1-tar.gz
+   tar xzf lucene-X.Y.Z.tar.gz lucene-X.Y.Z/docs/api
  
-   lucene-1.9-rc1/docs/api
+   mv lucene-X.Y.Z/docs/api api
+ }}}
+    1. Update nightly.sh in SVN (via Hudson's account on zones is the easiest way) with the
new version for publishing the Maven artifacts.  Ask Grant or Michael B. for help, as they
have zones accounts
  
+ = Announcing =
-   mv lucene-1.9-rc1/docs/api api
- }}}
-  1. Start a new, empty section in CHANGES.txt for the next release.
- (Ideally we could automate much of this.)
-  1. Update the doap file for projects.apache.org
-  1. Update nightly.sh in SVN (via Hudson's account on zones is the easiest way) with the
new version for publishing the Maven artifacts.  Ask Grant or Michael B. for help, as they
have zones accounts
  
+    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. Announce the release on [http://www.freshmeat.net]
+    1. Ensure the latest Lucene Jar + MD5 sum file have been pushed to http://repo1.maven.org/maven2/org/apache/lucene/
by deploying the distribution to http://people.apache.org/repo/m2-ibiblio-rsync-repository/
(that is minotaur.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository).  From
there it will be pushed to the central Maven repositories (both Maven 1 and Maven 2) automatically
in a few hours. Contact repository@apache.org if there's some problem.
+    1. Go to the JIRA "Manage Versions" Administration page (http://issues.apache.org/jira/secure/project/ManageVersions.jspa?pid=12310110)
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 =
+ 
+  * [http://www.apache.org/dev/release.html Apache Releases FAQ]
+ 

Mime
View raw message