Release your project

markfisher edited this page Dec 20, 2011 · 15 revisions

This release process applies to all git-based Spring projects built using the shared Gradle sources. It assumes that build masters are releasing projects manually on their own machines, or possibly when remotely logged into the build server. With the resolution of GRADLE-24, an alternate process will be published that allows for releasing projects from SpringSource's CI server.

What you will need

Contact sysadmin at springsource dot com for permissions, S3 keys, or other access-related issues.

  • Ability to connect to the VMware VPN in order to publish artifacts
  • A reasonably fast internet connection in order to publish artifacts
  • Git 1.7.2 or better in order to clone, commit, tag and push version changes
  • Git write access to the project being released in order to push version changes and tags
  • Access keys to dist.springframework.org and maven.springframework.org S3 buckets in order to publish dist zip and Maven artifacts
  • Key-based SSH authentication to static.springframework.org in order to publish docs
  • Membership in the 'springorg' group on static.springframework.org in order to have write access to docs directories
  • A $HOME/.gradle/gradle.properties file as per the sample buildmaster gradle.properties
  • (GA releases only) Subversion 1.6.5 or better
  • (GA releases only) Local checkout of and write access to https://springframework.svn.sourceforge.net/svnroot/springframework/repos/repo why?

Steps

When releasing from your own machine, note that certain settings may be out of sync with those on the CI server. For example, the CI server may explicitly specify JAVA_HOME pointing to a Java 5 JDK, ensuring Java 5 compatibility. You may have Java 6 on your local box, and could therefore theoretically introduce Java 6-only syntax or classes without warning. Normally, this will not be a problem as such changes are not usually made during a release. Generally speaking, you may simply want to double check the configuration of your CI build to ensure you're in sync.

For initial release

  1. Set up a project homepage on springsource.org
  2. Understand the benign error on first upload to S3

For every release

For clarity these below use Spring Integration git URLs, versions, directories, etc. Replace these values as appropriate.

  1. git clone [[--recursive|git submodule essentials]] git@github.com:SpringSource/spring-integration.git why do a fresh clone?
  2. Edit gradle.properties and change springIntegrationVersion to the release version, e.g. 2.1.0.RC2
  3. GRADLE_OPTS='-XX:MaxPermSize=1024m -Xmx1024m' ./gradlew build and verify artifacts before publication
  4. git commit -am'Release version 2.1.0.RC2'
  5. git tag v2.1.0.RC2 based on best practices for tagging
  6. Connect to the VPN, ./gradlew uploadArchives and verify artifacts after publication
  7. Edit gradle.properties and change springIntegrationVersion to the next development version, e.g. 2.1.0.BUILD-SNAPSHOT
  8. git commit -am'Update version to 2.1.0.BUILD-SNAPSHOT'
  9. (GA releases only): synchronize with Maven Central
cd $MAVEN_SYNC_REPO && svn stat | grep ? | cut -b8- | xargs svn add
svn stat # ensure everything looks as it should
svn commit -m"Spring Integration 2.1.0.RELEASE"
  1. git push && git push --tags why wait so long to push?