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=47&rev2=48 -------------------------------------------------- 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 1. Update the version numbers in common-build.xml on the branch: - * 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. commit the changes to both trunk and branch 1. On the branch, compile the code and run unit tests. - . {{{ant -Dversion=X.Y.M -Dspecversion=X.Y.M clean test}}} + . {{{ant -Dversion=X.Y.M -Dspecversion=X.Y.M -Dmaven_version=X.Y.M 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. Commit the build.xml and documentation changes from the previous few steps. 1. Build the release (see the later step on prepare-release also once you are experienced with doing the next steps by hand) - . {{{ant -Dversion=X.Y.M -Dspecversion=X.Y.M package}}} + . {{{ant -Dversion=X.Y.M -Dspecversion=X.Y.M }}}{{{-Dmaven_version=X.Y.M }}}{{{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. 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}}} @@ -63, +63 @@ * 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. If you are doing the 'ant prepare-release' approach, you can simply upload solr.tar to your public staging space on people.a.o. * On people.a.o when doing 'ant prepare-release', untar solr.tar and then untar solr-maven.tar - 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. Run it as: + 1. {{{ant -Dversion=X.Y.M -Dspecversion=X.Y.M -Dmaven_version=X.Y.M prepare-release}}} 1. /!\ :TODO: /!\ Hook in auto verification of signatures, figure out a way to enter the passphrase just once. 1. Tag the release:
