You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jclouds.apache.org by Apache Wiki <wi...@apache.org> on 2014/05/26 19:58:56 UTC

[Jclouds Wiki] Update of "Releasing jclouds" by EverettToews

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=43&rev2=44

  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)
    * Run {{{mvn --version}}} and verify that you are using a Java 6 JDK for 1.6.x releases
-   * Prepare the release. e.g.:
+   * 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
  }}}
-   * Remember to replace "jclouds-1.6.3-rcX" and the versions with the correct tag/version for the repo/release/RC you're building.
+   * Maven will ask you some questions:
+    * There are still some remaining snapshot dependencies. Do you want to resolve them now? yes
+    * Dependency type to resolve,: specify the selection number: 0
+    * 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
    * 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.
    * Perform the release build. e.g.,: