Dear Wiki user,

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

The "HowToRelease" page has been changed by GrantIngersoll.
http://wiki.apache.org/solr/HowToRelease?action=diff&rev1=42&rev2=43

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

  <<TableOfContents>>
  
  = Release Planning =
- 
  Start a discussion on solr-dev about having a release, questions to bring 
up...
  
-     * Any unresolved Jira issues with the upcoming version number listed as 
the "Fix Version"
+  * Any unresolved Jira issues with the upcoming version number listed as the 
"Fix Version"
-     * Any 
[[https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310230&fixfor=-1&resolution=1&sorter/field=issuekey&sorter/order=DESC&sorter/field=updated&sorter/order=DESC|"Fixed"
 Jira issues missing a "Fix Version"]] that should be updated to indicate that 
there were fixed in this upcoming version
+  * Any 
[[https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310230&fixfor=-1&resolution=1&sorter/field=issuekey&sorter/order=DESC&sorter/field=updated&sorter/order=DESC|"Fixed"
 Jira issues missing a "Fix Version"]] that should be updated to indicate that 
there were fixed in this upcoming version
-     * Does any documentation needs an updated?  Any necessary notes on 
upgrading for CHANGES.txt?
+  * Does any documentation needs an updated?  Any necessary notes on upgrading 
for CHANGES.txt?
-     * Who is going to be the "release engineer" ?
+  * Who is going to be the "release engineer" ?
-     * What day should be targeted for the release ?  (leave buffer time for a 
code freeze and release candidate testing; make sure at least a few people 
commit to having time to help test the release candidates around the target 
date.)
+  * What day should be targeted for the release ?  (leave buffer time for a 
code freeze and release candidate testing; make sure at least a few people 
commit to having time to help test the release candidates around the target 
date.)
  
  = Code Freeze =
+ For 7-14 days prior to the release target date, have a "code freeze" where 
committers agree to only commit things if they:
  
- For 7-14 days prior to the release target date, have a "code freeze" where 
committers agree to only commit things if they:
   * Are documentation improvements (including fixes to eliminate Javadoc 
warnings)
   * Are new test cases that improve test coverage
   * Are bug fixes found because of improved test coverage
   * Are new tests and bug fixes for new bugs encountered by manually testing
  
  = Steps For Release Engineer (and others helping) =
- 
  == Before building release ==
   1. Check that Solr works on the latest versions of Jetty, Tomcat, and Resin.
   1. Double Check that there are no remaining unresolved Jira issues with the 
upcoming version number listed as the "Fix" version
@@ -32, +30 @@

   1. Make sure the Ant sign-artifacts target is in sync with all of the 
artifacts that are created.  All released artifacts must be signed.
  
  == Making a release ==
-         1. Run RAT (http://incubator.apache.org/rat/) on the source.  ant 
rat-sources.  See https://issues.apache.org/jira/browse/SOLR-762.
+  1. Run RAT (http://incubator.apache.org/rat/) on the source.  ant 
rat-sources.  See https://issues.apache.org/jira/browse/SOLR-762.
-       1. Check if documentation needs an update, update release date in 
CHANGES.txt and add any necessary notes on upgrading.
+  1. Check if documentation needs an update, update release date in 
CHANGES.txt and add any necessary notes on upgrading.
-       1. Update news in 
{{{src/site/src/documentation/content/xdocs/index.xml}}} and for main 
lucene.apache.org site stored at https://svn.apache.org/repos/asf/lucene/site/. 
The second change may require additional rights or patch submitted to the 
Lucene PMC
+  1. Update news in {{{src/site/src/documentation/content/xdocs/index.xml}}} 
and for main lucene.apache.org site stored at 
https://svn.apache.org/repos/asf/lucene/site/. The second change may require 
additional rights or patch submitted to the Lucene PMC
-       1. Commit these changes.
+  1. Commit these changes.
-            '''Note:''' It is important to do this prior to the build so that 
it is reflected in the copy of the website included with the release for 
documentation purposes.
+   . '''Note:''' It is important to do this prior to the build so that it is 
reflected in the copy of the website included with the release for 
documentation purposes.
-       1. If this is the first release in a series (i.e. relase X.Y.0):
+  1. If this is the first release in a series (i.e. relase X.Y.0):
-            1. create a branch for the series: {{{
+   1. create a branch for the series:
+   {{{
  svn copy https://svn.apache.org/repos/asf/lucene/solr/trunk \
-   https://svn.apache.org/repos/asf/lucene/solr/branches/branch-X.Y -m 
"Starting Solr X.Y branch." 
+   https://svn.apache.org/repos/asf/lucene/solr/branches/branch-X.Y -m 
"Starting Solr X.Y branch."
  }}}
-            1. Create a new distribution directory: 
{{{people.apache.org:/www/www.apache.org/dist/lucene/solr/X.Y}}}
+   1. Create a new distribution directory: 
{{{people.apache.org:/www/www.apache.org/dist/lucene/solr/X.Y}}}
-       1. Check out the branch with:           {{{svn co 
https://svn.apache.org/repos/asf/lucene/solr/branches/branch-X.Y \}}}
+  1. Check out the branch with:           {{{svn co 
https://svn.apache.org/repos/asf/lucene/solr/branches/branch-X.Y \}}}
-            '''Note:''' at the moment releases need to be done on a unix box 
or in a cygwin environment with unix linefeeds, because fixcrlf is only done on 
the sources in the zip artifact 
+   . '''Note:''' at the moment releases need to be done on a unix box or in a 
cygwin environment with unix linefeeds, because fixcrlf is only done on the 
sources in the zip artifact
-       1. Update the version numbers in common-build.xml:
+  1. Update the version numbers in common-build.xml on the trunk:
-             * {{{specversion}}} should be set to `X.Y.M.${dateversion}`, 
where X.Y.M is the release being made.
+   * {{{specversion}}} should be set to `X.Y.M.${dateversion}`, where X.Y.M is 
the release being made.
-             * {{{version}}} should be set to `X.Y.N-dev`, where N is one 
greater than the release being made.
+   * {{{version}}} should be set to `X.Y.N-dev`, where N is one greater than 
the release being made.
-             * {{{maven_version}}} should be the same as {{{version}}} for 
release but set to X.Y-SNAPSHOT for non-release.
+   * {{{maven_version}}} should be the same as {{{version}}} for release but 
set to X.Y-SNAPSHOT for non-release.
+  1. Update the version numbers in common-build.xml on the newly created branh:
+   * {{{specversion}}} should be set to `X.Y.M`, where X.Y.M is the release 
being made.
+   * {{{version}}} should be set to `X.Y.N`, where N is one greater than the 
release being made.
+   * {{{maven_version}}} should be the same as {{{version}}}
+  1. commit the changes to both trunk and branch
-       1. Compile the code and run unit tests.
+  1. On the branch, compile the code and run unit tests.
-                {{{ant -Dversion=X.Y.M -Dspecversion=X.Y.M clean test}}}
+   . {{{ant clean test}}}
-         1. Regenerate the "site" docs per [[Website_Update_HOWTO]] so the 
documentation included with this release will reflect the correct version 
number (at the moment, this is specific to the tutorial)
+  1. Regenerate the "site" docs per [[Website_Update_HOWTO]] so the 
documentation included with this release will reflect the correct version 
number (at the moment, this is specific to the tutorial)
-       1. Commit the build.xml and documentation changes from the previous few 
steps.  
+  1. Commit the build.xml and documentation changes from the previous few 
steps.
-       1. Build the release.
-                {{{ant -Dversion=X.Y.M -Dspecversion=X.Y.M package}}}
+  1. Build the release (see step 17 also).
+   . {{{ant package}}}
-       1. Check that release tgz/zip files looks ok - e.g. uncompress them, 
run example, work through the steps of the tutorial, ensure that the javadocs 
are readable, etc... 
+  1. Check that release tgz/zip files looks ok - e.g. uncompress them, run 
example, work through the steps of the tutorial, ensure that the javadocs are 
readable, etc...
-       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).
+  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 dist/apache-solr-X.Y.M.tgz.asc 
--detach-sig dist/apache-solr-X.Y.M.tgz}}}
+   * {{{gpg --armor --output dist/apache-solr-X.Y.M.tgz.asc --detach-sig 
dist/apache-solr-X.Y.M.tgz}}}
-               * {{{gpg --armor --output dist/apache-solr-X.Y.M.zip.asc 
--detach-sig dist/apache-solr-X.Y.M.zip}}}
+   * {{{gpg --armor --output dist/apache-solr-X.Y.M.zip.asc --detach-sig 
dist/apache-solr-X.Y.M.zip}}}
-                 * /!\ :TODO: /!\  Sign the Maven artifacts.  See 
https://issues.apache.org/jira/browse/SOLR-776
+   * /!\ :TODO: /!\  Sign the Maven artifacts.  See 
https://issues.apache.org/jira/browse/SOLR-776
-                 * See the sign-artifacts target in the build.xml and the 
associated macrodefs in the common-build.xml file.
+   * See the sign-artifacts target in the build.xml and the associated 
macrodefs in the common-build.xml file.
-         1. Produce one or more release candidates using the steps outlined 
here, up to the point of actually tagging the release and distributing it.  Ask 
on solr-dev (cc [email protected]) for reviewers of the release 
candidates.  When a consensus emerges, build the final release candidate and 
call a vote.  3 +1 Lucene PMC votes are technically needed for a release, 
although the Solr considers all votes equally. (see 
[[http://www.apache.org/foundation/voting.html#ReleaseVotes|voting]]). A Hudson 
job has been setup to help in creating and hosting Solr Release Candidates 
(named: "Solr Release Candidate").  Note the Hudson job does not do the signing 
required in the previous step, so the final release (at least) will need the 
signing step.
+  1. Produce one or more release candidates using the steps outlined here, up 
to the point of actually tagging the release and distributing it.  Ask on 
solr-dev (cc [email protected] ) for reviewers of the release 
candidates.  When a consensus emerges, build the final release candidate and 
call a vote.  3 +1 Lucene PMC votes are technically needed for a release, 
although the Solr considers all votes equally. (see 
[[http://www.apache.org/foundation/voting.html#ReleaseVotes|voting]]). A Hudson 
job has been setup to help in creating and hosting Solr Release Candidates 
(named: "Solr Release Candidate").  Note the Hudson job does not do the signing 
required in the previous step, so the final release (at least) will need the 
signing step.
-         1. Now that you have read this, and done it at least once, know that 
there is an Ant target named prepare-release that takes care of much of this.  
You should still validate the docs, etc. and do the necessary checking.  
Calling prepare-release will call sign-artifacts.  You will be prompted to 
enter you Code signing key numerous times, once per artifact that needs to be 
signed.  This is a very important step.
+  1. Now that you have read this, and done it at least once, know that there 
is an Ant target named prepare-release that takes care of much of this.  You 
should still validate the docs, etc. and do the necessary checking.  Calling 
prepare-release will call sign-artifacts.  You will be prompted to enter you 
Code signing key numerous times, once per artifact that needs to be signed.  
This is a very important step.
-         1. /!\ :TODO: /!\  Hook in auto verification of signatures, figure 
out a way to enter the passphrase just once.
+  1. /!\ :TODO: /!\  Hook in auto verification of signatures, figure out a way 
to enter the passphrase just once.
-       1. Tag the release: {{{
+  1. Tag the release:
+  {{{
  svn copy https://svn.apache.org/repos/asf/lucene/solr/branches/branch-X.Y \
     https://svn.apache.org/repos/asf/lucene/solr/tags/release-X.Y.M -m "Solr 
X.Y.M release."
  }}}
-         1. Copy release files to the distribution directory.
+  1. Copy release files to the distribution directory.
-                 1. {{{scp -p dist/apache-solr-X.Y.M.tar.gz* 
people.apache.org:/www/www.apache.org/dist/lucene/solr/X.Y}}}
+   1. {{{scp -p dist/apache-solr-X.Y.M.tar.gz* 
people.apache.org:/www/www.apache.org/dist/lucene/solr/X.Y}}}
-                 1. {{{scp -p dist/apache-solr-X.Y.M.zip* 
people.apache.org:/www/www.apache.org/dist/lucene/solr/X.Y}}}
+   1. {{{scp -p dist/apache-solr-X.Y.M.zip* 
people.apache.org:/www/www.apache.org/dist/lucene/solr/X.Y}}}
-         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/solr
+  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/solr
-         1. Ensure that the most current keys file is on the distribution site:
+  1. Ensure that the most current keys file is on the distribution site:
-            {{{scp -p KEYS 
people.apache.org:/www/www.apache.org/dist/lucene/solr/}}}
+   . {{{scp -p KEYS people.apache.org:/www/www.apache.org/dist/lucene/solr/}}}
-       1. Start a new section in CHANGES.txt
+  1. Start a new section in CHANGES.txt
-       1. Wait 24 hours for release to propagate to mirrors.
+  1. Wait 24 hours for release to propagate to mirrors.
-         1. Add the new release info to the 
[[http://svn.apache.org/repos/asf/lucene/solr/trunk/site/doap.rdf|doap.rdf]] 
file, and double check for any other updates that should be made to the doap 
file as well if it hasn't been updated in a while. (Note: this file is used to 
power [[http://projects.apache.org/projects/solr.html|Solr's Listing]] on 
http://projects.apache.org/ as well as the 
[[http://projects.apache.org/feeds/rss.xml|Recent Apache Releases]] RSS feed)
+  1. Add the new release info to the 
[[http://svn.apache.org/repos/asf/lucene/solr/trunk/site/doap.rdf|doap.rdf]] 
file, and double check for any other updates that should be made to the doap 
file as well if it hasn't been updated in a while. (Note: this file is used to 
power [[http://projects.apache.org/projects/solr.html|Solr's Listing]] on 
http://projects.apache.org/ as well as the 
[[http://projects.apache.org/feeds/rss.xml|Recent Apache Releases]] RSS feed)
-       1. Deploy new Solr site.
+  1. Deploy new Solr site.
-       1. Deploy new main Lucene site.
+  1. Deploy new main Lucene site.
-       1. Update Javadoc in 
{{{people.apache.org:/www/lucene.apache.org/solr/docs/api}}}.
+  1. Update Javadoc in 
{{{people.apache.org:/www/lucene.apache.org/solr/docs/api}}}.
-            NOTE: skip this for now, as this javadoc is currently updated 
automatically from the nightly build
+   . NOTE: skip this for now, as this javadoc is currently updated 
automatically from the nightly build
-       1. Send announcements to the solr-user@, solr-dev@, and general@ lucene 
mailing lists.
+  1. Send announcements to the solr-user@, solr-dev@, and general@ lucene 
mailing lists.
  
  == Post Release ==
   * Housekeeping
-    * Mark the version as "released" in Jira (noting the release date)
+   * Mark the version as "released" in Jira (noting the release date)
-    * Create the next version in Jira (if it doesn't already exist)
+   * Create the next version in Jira (if it doesn't already exist)
-    * 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".
+   * 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".
   * Publicity
-    * update freshmeat (Yonik owns the project on Freshmeat, he may need to do 
this one)
+   * update freshmeat (Yonik owns the project on Freshmeat, he may need to do 
this one)
-    * !TheServerSide blurb (http://www.theserverside.com/news/post.tss)
+   * !TheServerSide blurb (http://www.theserverside.com/news/post.tss)
-    * blog away
+   * blog away
   * Documentation
-    * Change wiki to match current best practices (remove/change deprecations, 
etc)
+   * Change wiki to match current best practices (remove/change deprecations, 
etc)
  
  = Related Resources =
- 
   * http://www.apache.org/dev/#releases
   * http://www.apache.org/dev/#mirror
  
  = :TODO: Things To Cleanup in this document =
- 
  /!\ :TODO: /!\
  
-  
- 

Reply via email to