Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jclouds Wiki" for change notification.
The "Releasing jclouds" page has been changed by AndrewPhillips: https://wiki.apache.org/jclouds/Releasing%20jclouds?action=diff&rev1=11&rev2=12 Comment: Adding more detailed instructions on updating <jclouds.version> and similar properties 3. Check out the branch to be released in each repo. 4. Update any POM properties in the repos pointing at the SNAPSHOT version and change those to the release version. 5. Run mvn release commands for each repo, in order, as described below. - 6. Push the branches and RC tags to the remote repos. + 6. Push the release commits and RC tags to the remote repos. 7. Close the Nexus staging repository. 8. Copy the source release tarballs, signatures and hashes to a new release candidate directory. 9. Email the dev list, opening the 72 hour vote window on the RC. @@ -63, +63 @@ * For each of those repos, in that order, do the following: * Check out the branch you're going to be releasing from - e.g., 1.6.x * Check that your [[https://help.github.com/articles/setting-your-username-in-git|Git username]] and [[https://help.github.com/articles/setting-your-email-in-git|email]] are set to match your Apache account - * Check the (repo)/pom.xml and/or (repo)/project/pom.xml for any properties referencing the SNAPSHOT version we're leaving, and replace those with the release version. + * Check the <repo>/pom.xml and/or <repo>/project/pom.xml for any properties (typically {{{<jclouds.version>}}}) referencing the SNAPSHOT version we're leaving, and replace those with the release version. Commit the changes, as otherwise the following step will complain about uncommitted local modifications * Prepare the release. e.g.: {{{ mvn release:clean release:prepare -DreleaseVersion=1.6.1-incubating -Dtag=jclouds-1.6.1-incubating-rcX -DdevelopmentVersion=1.6.2-SNAPSHOT -DpushChanges=false }}} - * Keep an eye out for [[https://issues.apache.org/jira/browse/JCLOUDS-225|JCLOUDS-225]], which affects the Karaf release - * Remember to replace "jclouds-1.6.1-incubating-rcX" and the versions with the correct tag/version for the repo/release/RC you're building. + * Remember to replace "jclouds-1.6.1-incubating-rcX" and the versions with the correct tag/version for the repo/release/RC you're building. - * Some repositories (most notably labs and karaf) may have strange build problems with the new version when you run release:prepare. If that happens, run {{{mvn clean install -DskipTests}}} with the POMs set to the release version, and then try running the prepare command again. + * Some repositories (most notably labs and karaf) may have strange build problems with the new version when you run release:prepare. If that happens, run {{{mvn clean install -DskipTests}}} with the POMs set to the release version, and then try running the prepare command again. Keep an eye out for [[https://issues.apache.org/jira/browse/JCLOUDS-225|JCLOUDS-225]], which affects the Karaf release - * Note that this will explicitly and specifically *not* push the tag or branch to the remote incubator-(whatever).git. That is by design, to make it easier to recover from errors and to speed up the release build. You will need to push the tag and branch upon completion of the build. + * Note that this will explicitly and specifically *not* push the tag or branch to the remote incubator-(whatever).git. That is by design, to make it easier to recover from errors and to speed up the release build. You will need to push the tag and branch upon completion of the build. * Perform the release build. e.g.,: {{{ mvn clean release:perform -DconnectionUrl=scm:git:file://`pwd`/.git -Dtag=jclouds-1.6.1-incubating-rcX -Darguments="-DskipTests" }}} - * We deliberately do not run the tests in the release build, since we already just ran them for the prepare build, and that just seems redundant. + * We deliberately do not run the tests in the release build, since we already just ran them for the prepare build, and that just seems redundant. - * Jars will be deployed to repository.apache.org, in a new staging repo (if this is the first of the repos you're building) or the existing one used for the previous repos (if you've already built incubating-jclouds.git). Remember that you need to have an account on repository.apache.org and your GPG key set up (as described above) or the build will fail. + * JARs will be deployed to repository.apache.org, in a new staging repo (if this is the first of the repos you're building) or the existing one used for the previous repos (if you've already built incubating-jclouds.git). Remember that you need to have an account on repository.apache.org and your GPG key set up (as described above) or the build will fail. + * For those repos where we added a commit to update {{{<jclouds.version>}}} and similar properties, bump the properties to the next development SNAPSHOT version and commit the change - * Push the tag and the current branch to the remote repo. + * Push the tag and the release commit to the remote repos - * For 1.6.1-incubating, we didn't push the second commit the release plugin applies, changing the version to 1.6.2-SNAPSHOT. Going forward, we should still do that. If we need to spin a second release candidate, we'll do by creating a new 1.6.2 (or whatever) branch from the last commit before the version changed to the release version, and re-run subsequent RCs there. + * We don't push the second commit the release plugin applies, changing the version to 1.6.2-SNAPSHOT, or the commits that change {{{<jclouds.version>}}} and similar properties, yet. If we need to spin a second release candidate, we'll do by creating a new 1.6.2 (or whatever) branch from the last commit before the version changed to the release version, and re-run subsequent RCs there. * Go to [[https://git-wip-us.apache.org/repos/asf?p=incubator-jclouds.git]] (or equivalent) and find the link to the tag you just pushed - copy that aside, since you'll need it for the vote email. * Once you've finished building all of the repos, go to [[https://repository.apache.org]], log in, and go to Staging Repositories. Find the open org.apache.jclouds repository, which your builds have been uploading to. Select it and close it. That'll take a little while. Then copy the URL for the repo - you'll need that shortly. @@ -153, +153 @@ === Actually Releasing === * First, in each of the repos, create and push a new tag, like jclouds-1.6.1-incubating, pointing at the same commit as the RC tag we included in the vote emails. Push those tags to the remote. + * Push the second commit made by the release plugin (which updates the POM versions to the next SNAPSHOT), and commits made to update {{{<jclouds.version>}}} and similar properties * Checkout https://dist.apache.org/repos/dist/release/incubator/jclouds. Create a new directory for the release, i.e., 1.6.1-incubating. Copy the release artifacts from the RC into that directory. Point the stable symlink to that new directory. svn add the new directory and the stable symlink, as well as svn rm'ing any old releases in the same line (i.e., any older 1.6.x releases) - these are archived on archive.apache.org, but shouldn't be in the primary dist area. svn ci - your added files should show up on [[http://www.apache.org/dist/incubator/jclouds]] shortly, but will take a while to propagate to the various mirrors. * While waiting, go to [[https://repository.apache.org]], log in, and go to Staging Repositories. Select the staging repo for the RC, and click Release - this will move the artifacts into the releases repo, and from there they'll be synced to Maven Central as well. * If you've got admin access to JIRA, mark the version you just released as, well, released, and if the next version in the train doesn't already exist, create it. If you're not in the JIRA admins for jclouds, drop an email to the dev list asking for someone to do this.
