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 AndrewBayer: https://wiki.apache.org/jclouds/Releasing%20jclouds New page: = How to release (and test RCs) for Apache jclouds (incubating) = == Cutting an RC == === Running the RC build === * The repo order to run the RC build is: * incubating-jclouds.git * incubating-jclouds-labs.git * incubating-jclouds-chef.git * incubating-jclouds-karaf.git * incubating-jclouds-cli.git * 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 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. * 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}}} * 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. * 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. * 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. * Push the tag and the current branch to the remote repo. * 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.
