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 EverettToews: https://wiki.apache.org/jclouds/Releasing%20jclouds?action=diff&rev1=44&rev2=45 == Cutting an RC == === Running the RC build === - * The repo order to run the RC build is: + 1. The repo order to run the RC build is: - * jclouds.git + 1. jclouds.git - * jclouds-labs.git + 1. jclouds-labs.git - * jclouds-labs-openstack.git + 1. jclouds-labs-openstack.git - * jclouds-labs-aws.git (if 1.7 or later) + 1. jclouds-labs-aws.git (if 1.7 or later) - * jclouds-labs-google.git (if 1.7 or later) + 1. jclouds-labs-google.git (if 1.7 or later) - * jclouds-chef.git + 1. jclouds-chef.git - * jclouds-karaf.git + 1. jclouds-karaf.git - * jclouds-cli.git + 1. jclouds-cli.git - * For each of those repos, in that order, do the following: + 1. 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 + 1. 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 + 1. 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 (typically {{{<jclouds.version>}}}) referencing the SNAPSHOT version we're leaving, and replace those with the release version. The following command can help finding all those versions: + 1. 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. The following command can help finding all those versions: {{{ find . -name pom.xml -exec grep -nH '1.6.3-SNAPSHOT' {} \; | grep -v '<version>' }}} - {{{ - find . -name pom.xml -exec grep -nH '1.6.3-SNAPSHOT' {} \; | grep -v '<version>' - }}} Commit the changes, as otherwise the following step will complain about uncommitted local modifications. - * For jclouds-labs-openstack.git, first run {{{mvn versions:update-parent -DparentVersion="[1.6.3]"}}} (or whatever the release version is). Commit and push. (Note - this may only be needed for 1.6.x) + 1. For jclouds-labs-openstack.git, first run {{{mvn versions:update-parent -DparentVersion="[1.6.3]"}}} (or whatever the release version is). Commit and push. (Note - this may only be needed for 1.6.x) - * Run {{{mvn --version}}} and verify that you are using a Java 6 JDK for 1.6.x releases + 1. Run {{{mvn --version}}} and verify that you are using a Java 6 JDK for 1.6.x releases + 1. Prepare the release. Remember to replace "jclouds-1.6.3-rcX" and the versions with the correct tag/version for the repo/release/RC you're building. e.g.: {{{ mvn release:clean release:prepare -DreleaseVersion=1.6.3 -Dtag=jclouds-1.6.3-rcX -DdevelopmentVersion=1.6.4-SNAPSHOT -DpushChanges=false }}} - * Prepare the release. Remember to replace "jclouds-1.6.3-rcX" and the versions with the correct tag/version for the repo/release/RC you're building. e.g.: - {{{ - mvn release:clean release:prepare -DreleaseVersion=1.6.3 -Dtag=jclouds-1.6.3-rcX -DdevelopmentVersion=1.6.4-SNAPSHOT -DpushChanges=false - }}} - * Maven will ask you some questions: + 1. Maven will ask you some questions: - * There are still some remaining snapshot dependencies. Do you want to resolve them now? yes + 1. There are still some remaining snapshot dependencies. Do you want to resolve them now? yes - * Dependency type to resolve,: specify the selection number: 0 + 1. Dependency type to resolve,: specify the selection number: 0 - * Which release version should it be set to? 1.6.3 + 1. Which release version should it be set to? 1.6.3 - * What version should the dependency be reset to for development? 1.6.4-SNAPSHOT + 1. What version should the dependency be reset to for development? 1.6.4-SNAPSHOT - * Some repositories (most notably labs and karaf) may have "missing dependency" 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. + 1. Some repositories (most notably labs and karaf) may have "missing dependency" 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. - * Note that this will explicitly and specifically '''not''' push the tag or branch to the remote (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. + 1. Note that this will explicitly and specifically '''not''' push the tag or branch to the remote (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.3-rcX -Darguments="-DskipTests" + 1. Perform the release build. e.g.,: {{{ mvn clean release:perform -DconnectionUrl=scm:git:file://`pwd`/.git -Dtag=jclouds-1.6.3-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. + 1. 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 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. + 1. 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 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 + 1. 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 release commit to the remote repos + 1. Push the tag and the release commit to the remote repos - * We don't push the second commit the release plugin applies, changing the version to 1.6.4-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.4 (or whatever) branch from the last commit before the version changed to the release version, and re-run subsequent RCs there. + 1. We don't push the second commit the release plugin applies, changing the version to 1.6.4-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.4 (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=jclouds.git]] (or equivalent) and find the link to the tag you just pushed - copy that and the assoicated commit hash aside, since you'll need them for the vote email. + 1. Go to [[https://git-wip-us.apache.org/repos/asf?p=jclouds.git]] (or equivalent) and find the link to the tag you just pushed - copy that and the assoicated commit hash aside, since you'll need them 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. + 1. 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. === Starting the Vote === - * Checkout https://dist.apache.org/repos/dist/dev/jclouds. Create a new directory for the RC, i.e., 1.6.3-rc0. + 1. Checkout https://dist.apache.org/repos/dist/dev/jclouds. Create a new directory for the RC, i.e., 1.6.3-rc0. - * Go to the candidate directory and run the following, substituting the correct version and the now-closed staging repository accordingly. This will copy down all the source tarballs, their signatures and their checksums. + 1. Go to the candidate directory and run the following, substituting the correct version and the now-closed staging repository accordingly. This will copy down all the source tarballs, their signatures and their checksums. {{{ /home/abayer/bin/fetch_jclouds_rc.sh 1.6.3 https://repository.apache.org/content/repositories/orgapachejclouds-016 }}} - * It's not a bad idea to try taking each of the tarballs, blowing them up and then building, with a standard {{{mvn clean install}}}. Remember that RAT checks are done as part of the Maven build, so you don't need to run those separately. + 1. It's not a bad idea to try taking each of the tarballs, blowing them up and then building, with a standard {{{mvn clean install}}}. Remember that RAT checks are done as part of the Maven build, so you don't need to run those separately. - * svn add the new directory, as well as svn rm'ing any old RCs in the same line (i.e., any older 1.6.x RC). svn ci, and use that link under https://dist.apache.org/repos/dist/dev/jclouds/ for the release vote email. + 1. svn add the new directory, as well as svn rm'ing any old RCs in the same line (i.e., any older 1.6.x RC). svn ci, and use that link under https://dist.apache.org/repos/dist/dev/jclouds/ for the release vote email. - * Get the JIRA release notes for the release by going to [[https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12314430]] and choosing HTML and the version you're releasing. Save that link for inclusion in the vote/discuss emails. + 1. Get the JIRA release notes for the release by going to [[https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12314430]] and choosing HTML and the version you're releasing. Save that link for inclusion in the vote/discuss emails. - * Send two emails to [email protected], a [VOTE] thread and a [DISCUSS] thread. Set an end time for the vote, generally 72 hours from when you're sending it (but it's generally considerate to round up, and not a bad idea to give an extra day if the release vote window goes over the weekend). Example templates for the emails are below. Replace links, versions, RC numbers, release note link, etc. + 1. Send two emails to [email protected], a [VOTE] thread and a [DISCUSS] thread. Set an end time for the vote, generally 72 hours from when you're sending it (but it's generally considerate to round up, and not a bad idea to give an extra day if the release vote window goes over the weekend). Example templates for the emails are below. Replace links, versions, RC numbers, release note link, etc. - * [VOTE] email: + 1. [VOTE] email: {{{ Subject: [VOTE] Release Apache jclouds 1.6.3 RC3 Body: @@ -163, +154 @@ }}} === Cancelling the PMC Vote === - * If, for some reason (e.g. a -1 that is not resolved), the vote needs to be cancelled: + 1. If, for some reason (e.g. a -1 that is not resolved), the vote needs to be cancelled: - * Reply to the [VOTE] thread on [email protected] announcing the cancellation of the vote. Modify the template as appropriate. + 1. Reply to the [VOTE] thread on [email protected] announcing the cancellation of the vote. Modify the template as appropriate. {{{ Subject: [CANCEL][VOTE] Release Apache jclouds 1.6.3 RC3 Body: This vote is being cancelled due to issues uncovered during validation. A new release candidate will be created once these issues have been addressed. Thank you. }}} - * Revert (using {{{git revert}}}) the release commits and push them to the remote repos. + 1. Revert (using {{{git revert}}}) the release commits and push them to the remote repos. - * If applicable, commit any additional changes required to resolved the issues identified, and push these too. + 1. If applicable, commit any additional changes required to resolved the issues identified, and push these too. - * Respin + 1. Respin === Finishing the PMC Vote === - * If, after the voting window is closed, there are at least three binding +1s and no binding -1s, the PMC has signed off on the release and it can, well, be released. + 1. If, after the voting window is closed, there are at least three binding +1s and no binding -1s, the PMC has signed off on the release and it can, well, be released. - * Reply to the [VOTE] thread on [email protected] announcing the closure of the vote, regardless of its outcome, and give the vote counts. Modify the template as appropriate. + 1. Reply to the [VOTE] thread on [email protected] announcing the closure of the vote, regardless of its outcome, and give the vote counts. Modify the template as appropriate. {{{ Subject: [RESULT][VOTE] Release Apache jclouds 1.6.3 RC3 Body: The vote is now closed, and with X binding +1s, we're ready to release/this vote has not passed. }}} - * Assuming the vote has passed, it's time to release! + 1. Assuming the vote has passed, it's time to release! === Actually Releasing === - * First, in each of the repos, create and push a new tag, like jclouds-1.6.3, pointing at the same commit as the RC tag we included in the vote emails. Push those tags to the remote. + 1. First, in each of the repos, create and push a new tag, like jclouds-1.6.3, 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 + 1. 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 - * For jclouds-labs-openstack, also run {{{mvn versions:update-parent -DparentVersion="[1.6.4-SNAPSHOT]"}}} or whatever the new version is, commit, push. + 1. For jclouds-labs-openstack, also run {{{mvn versions:update-parent -DparentVersion="[1.6.4-SNAPSHOT]"}}} or whatever the new version is, commit, push. - * Checkout https://dist.apache.org/repos/dist/release/jclouds. Create a new directory for the release, i.e., 1.6.3. 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/jclouds]] shortly, but will take a while to propagate to the various mirrors. + 1. Checkout https://dist.apache.org/repos/dist/release/jclouds. Create a new directory for the release, i.e., 1.6.3. 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/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. + 1. 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. + 1. 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. - * Once the release bits have shown up on the mirrors, send the following email, updating the content accordingly, to [email protected], [email protected] and [email protected]: + 1. Once the release bits have shown up on the mirrors, send the following email, updating the content accordingly, to [email protected], [email protected] and [email protected]: {{{ Subject: [ANNOUNCE] Apache jclouds 1.6.3 released Body: @@ -214, +205 @@ The Apache jclouds Team }}} - * And you're done! + 1. And you're done!
