> Cutting a release > ------------------------ > * Grab the latest changes in the official repo > * Run the > * Generate the binaries, publish them to ??? > * Tag the release > * Push the changes to the official repo. > > Sound good, minus the obvious missing details like where the binaries are > posted?
This sounds great. In fact, it's so great, it's exactly what Maven does automatically :) The above can be summarized into... mvn release:prepare (tell it your version number) (tell it your new dev version (3.2-SNAPSHOT)) mvn release:perform The release:prepare goal will take care of updating the pom.xml files, running the tests, committing the poms, and tagging the release. The release:perform step will checkout that tag build your release artifacts and automatically upload them to the repository of your choice. For example, I used the Maven release plugin to release 1.1.0 of the hibernate-memcached project http://github.com/raykrueger/hibernate-memcached/tree/hibernate-memcached-1.1.0 You can see the commit to pom.xml by the plugin where it updated the version to <version>1.1.0</version>. Running the release:perform goal pushed the binaries out to my svn repository (I use it as my maven repository) based on the values in the <distributionManagement> section of the pom. You can see the releases pushed to my maven repo at http://raykrueger.googlecode.com/svn/repository/com/googlecode/hibernate-memcached/ Unfortunately there's no way for me to automate the upload to the project homepage at googlecode (http://code.google.com/p/hibernate-memcached/) I upload those manually. _______________________________________________ Mailing list: https://launchpad.net/~erma-core Post to : erma-core@lists.launchpad.net Unsubscribe : https://launchpad.net/~erma-core More help : https://help.launchpad.net/ListHelp
