Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification.
The "CreatingReleases" page has been changed by GaryGregory. http://wiki.apache.org/commons/CreatingReleases?action=diff&rev1=42&rev2=43 -------------------------------------------------- = DRAFT Procedure for creating a release using M2 = - '''This is currently a discussion page, and is not (yet) policy''' == Maven2 Release Procedure == - As discussed here: http://markmail.org/message/3emjaadwpf7cr5q3 The Commons Parent POM (v10 onwards) defines repositories such that when using the {{{rc}}} profile, uploaded artifacts go to: + * The Apache {{{m2-snapshot-repository}}} if a SNAPSHOT version is used (to permit easy testing of RCs by community, for instance) * A staging repository under {{{p.a.o/builds/commons/{component.id}/}}} if a final version is used === A. Infrastructure Setup (one time) === - ==== A.1 Get Familiar with Maven ==== - Reading the Maven documentation is a good start - [[http://maven.apache.org/developers/release/releasing.html|Releasing A Maven Project]]. ==== A.2 Signature Keys ==== - You need to sign the released artifact using your PGP key which implies * you generated one @@ -28, +24 @@ * it is found in the KEY file (see https://svn.apache.org/repos/asf/commons/trunks-proper) See also: + * http://www.apache.org/dev/release-signing.html * http://www.gnupg.org/gph/en/manual.html * http://people.apache.org/~henkp/sig/pgp-key-signing.txt ==== A.3 Maven Installation ==== - After having a lot of problems (Oct. 2009) the following configuration is known to work + * Maven 2.2.1 * SVN 1.5.0 + However, on Un*x, you may encounter http://jira.codehaus.org/browse/MSITE-404 which will at least prevent staging a site. On Mac, you may also encounter http://jira.codehaus.org/browse/MRELEASE-424 for which there is a workaround. - However, on Un*x, you may encounter http://jira.codehaus.org/browse/MSITE-404 which will at least prevent - staging a site. On Mac, you may also encounter http://jira.codehaus.org/browse/MRELEASE-424 for which there is a workaround. ==== A.4 Maven Server Settings ==== - It is a good idea to check your ''settings.xml'' that it contains the corresponding server entries for the repositories and websites defined in the commons parent pom. If you have a different user name on your box than on ''people.apache.org'' you local user name will be used for authentication. Therefore the authentication will fail and after a few retries your are locked out from ''people.apache.org'' for a day - which in turn makes cutting a release rather lengthy. In theory you could also provide your password in the server section below but this unsafe and did not work in my case. {{{ @@ -67, +62 @@ </server> </servers> }}} - === B. Release Preparation === - ==== B.1 Check Your Project ==== - Here you find a list of reminders what to double-check before cutting a release candidate * Make sure that you are not referencing any SNAPSHOT version (dependencies and plugins) otherwise the release will fail @@ -83, +75 @@ * Make sure to add all missing committers and contributers ==== B.2 Prepare Your Version Number ==== - - A guideline regarding version numbering can be found at [[http://commons.apache.org/releases/versioning.html]] - within Commons we reached the following consensus + A guideline regarding version numbering can be found at http://commons.apache.org/releases/versioning.html - within Commons we reached the following consensus * when your release a new major or minor version it comes without point release number, e.g "foo-1.0.jar" or "foo-2.1.jar" * when doing a bugfix release your need to add the point release number, e.g "foo-1.0.1.jar" or "foo-2.1.1.jar" ==== B.3 Prepare Your Maven Variables ==== - During the staging process a directory is created on ''people.apache.org'' based on the content of the following Maven variables * commons.release.version is a duplicate of the pom version @@ -104, +94 @@ <commons.rc.version>RC2</commons.rc.version> </properties> }}} - ==== B.4 Update Your Download Page ==== - The commons-build plugin generates a download page in {{{./src/site/xdoc/}}} based on {{{commons.release.version}}} {{{ mvn commons:download-page }}} - ==== B.3 Define Staging Site for Release Candidate ==== - Also ensure that the {{{rc}}} profile will stage the site (rather than update the Commons component website). See bottom of [[http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/pom.xml|Commons SCXML POM]] as an example. See [[http://issues.apache.org/jira/browse/COMMONSSITE-26|COMMONSSITE-26]] for background. {{{ @@ -131, +117 @@ </distributionManagement> </profile> </profiles> - }}} - ==== B.5 Prepare Your Assembly Descriptors ==== - If you are declaring/using your own assembly descriptors make sure that they are not using ${version} but ${commons.release.version} - there seems to be an odd bug which results in an incorrectly expanded version string, e.g. {{{commons-exec-2.4.1-src}}}. If in doubt look at {{{./src/assembly/src.xml}}} ==== B.6 Commit Your Changes ==== - When you followed the instructions you have modified a couple of files by now - commit them now otherwise the release process will fail. ==== B.7 Dry Run Your Maven Release ==== - Check that your poms will not lose content when they are rewritten during the release process. * mvn release:prepare -!DdryRun=true @@ -153, +134 @@ * Remember to do 'mvn release:clean ' before you start the real release process. === C. Run The Release Process === - ==== C.1 Stage Artifacts and Site ==== - 1. {{{mvn -Prc release:prepare}}} 1. {{{mvn -Prc release:perform}}} ==== C.2 Remove SHA1 and MD5 Fingerprints of PGP Signatures ==== - During the release process some unwanted fingerprints of all ASCII-armored files are generated, e.g. "commons-foo.jar.asc.md5" and "commons-foo.jar.asc.sha1". It is a good idea to remove them manually for the time being. === D. Vote === - ==== D.1 Send Out The Vote ==== - Below you find a vote template to save you some time ... {{{ @@ -186, +162 @@ [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because - }}} - ==== D.2 React to the Vote ==== - If vote fails, undo and redo previous steps as appropriate (make sure you use a new tag, e.g. if RC2 fails, then create RC3). And rest assured that most releases need more than one release candidate ... :-) === E. Go live === - ==== E.1 Copy to "dist" ==== - We need to copy distribution archives to the Commons {{{dist/}}} area which is located on {{{people.apache.org}}} under {{{/www/www.apache.org/dist/commons}}}. (This content is also automatically copied to {{{archive.apache.org}}}.) We also need to update the "current" symlinks to point to the current version, using the {{{symlinks.sh}}} tool available in https://svn.apache.org/repos/private/committers/tools/releases/symlinks.sh Here's an example used for commons-dbutils: @@ -209, +180 @@ cd .. ~/svn/apache-committers/tools/releases/symlinks.sh 1.2 }}} - ==== E.2 Copy Artifacts from Staging ==== - The Maven Stage plugin copies the artifacts (from your release candidate) to the M2 sync directory (people.apache.org/repo/m2-ibiblio-rsync-repository). The following example was used to do the copy the artifacts for commonse-exec-1.0 based on RC5 @@ -222, +191 @@ -DtargetRepositoryId=apache.releases \ -Dversion=1.0 }}} - ==== E.3 Deploy the Site ==== + Run {{{mvn site-deploy}}} to deploy the site - please note that you are deploying the site of the next development snapshot. If your local username is not the same as your Apache username, run: {{{mvn -Duser.name=apachename site-deploy}}}. - - Run {{{mvn site-deploy}}} to deploy the site - please note that you are deploying the site of the next development snapshot. - If your local username is not the same as your Apache username, run: {{{mvn -Duser.name=apachename site-deploy}}}. ==== E.4 Create the SVN Release Tag ==== - If you have used a "RC" tag (e.g. "EXEC_1_0_1_RC5") for the M2 release preparation you need to copy the SVN tag in order to create an official release tag. The following example was used for creating the release tag on commons-exec-1.0.1 @@ -239, +204 @@ https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_1 \ -m "The RC5 passed to vote so this will be the release tag" }}} - === F. Celebrate === - ==== F.1 Prepare Your Celebration ==== - Make sure a couple of things * check the project website (mirroring takes a while) @@ -252, +214 @@ * check {{{http://repo1.maven.org/maven2/}}} and {{{ http://people.apache.org/repo/m2-ibiblio-rsync-repository/}}} if your project artifacts are available ==== F.2 Send an Announcement ==== - Send an announcement to the developer and user mailing list. Since you have dutifully updated your {{{changes.xml}}} you can generate the announcement in {{{./target/announcement/}}} {{{ > mvn changes:announcement-generate }}} - === G. Tidy up === - ==== G.1 Remove old releases ==== - Once the new release has been available for a few days, any files from previous releases should be deleted from the {{{binaries}}} and {{{source}}} directories. ---- == Releasing commons-parent pom == - - * Call a vote with a link showing the changes since the last release - example [[http://mail-archives.apache.org/mod_mbox/commons-dev/200801.mbox/%3c55afdc850801030530tb7f5a59x2ea1ac35b62ab...@mail.gmail.com%3e|here]] + * Call a vote with a link showing the changes since the last release - example [[http://mail-archives.apache.org/mod_mbox/commons-dev/200801.mbox/<55afdc850801030530tb7f5a59x2ea1ac35b62ab...@mail.gmail.com>|here]] + * Make sure the POM version is a SNAPSHOT version, for example {{{<version>18</version>}}} * If the vote passes, cut the release using the [[http://maven.apache.org/plugins/maven-release-plugin/index.html|maven-release-plugin]] - * command {{{svn up}}} (makes sure your svn copy is ''up-to-date'') + * command {{{svn up}}} (makes sure your svn copy is ''up-to-date'') - * command {{{mvn -Prelease release:prepare}}} + * command {{{mvn -Prelease release:prepare}}} - * command {{{mvn -Prelease release:perform}}} + * command {{{mvn -Prelease release:perform}}} ---- == Procedure for creating a release using M2 (outdated by above) == - This assumes that the Commons Proxy is about to vote on 1.0-RC3. * Tag "proxy-1.0-rc3" but with the version number set to "1.0". This is so the release does not have to be rebuilt later just to fix the version. @@ -287, +244 @@ * Check out the tag proxy-1.0-rc3 into a clean local working directory * Build the release artifacts - I think there's a couple of options here: - * Run the following maven command: + {{{mvn site javadoc:jar source:jar assembly:assembly}}} This will create all the artifacts - jars and src and binary distros, but then you need to create checksums and sign (James Carman: link to how to do this?) - - {{{mvn site javadoc:jar source:jar assembly:assembly}}} - - This will create all the artifacts - jars and src and binary distros, - but then you need to create checksums and sign (James Carman: link to how to do this?) * Run the following maven command: + {{{mvn -Prc -DcreateChecksum=true site install}}} This should create all the artifacts installed in your local m2 repository, signed and checksums (note it also creates checksums for signature files - I delete those) - - {{{mvn -Prc -DcreateChecksum=true site install}}} - - This should create all the artifacts installed in your local m2 - repository, signed and checksums (note it also creates checksums for - signature files - I delete those) * Upload the artifacts to people.apache.org/~<userid>/proxy-1.0-rc3 (e.g.) and call a vote on dev@ (James Carman: isn't there a mvn command to do this?) * Make sure that your signing key has been [[http://www.apache.org/dev/release-signing.html#keys-policy|added]] to the commons-wide KEYS file (http://svn.apache.org/repos/asf/commons/trunks-proper/KEYS) found in SVN. * The vote e-mail should include: - * URL for artifacts * URL for SVN tag * URL for website --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
