Release your project
Clone this wiki locally
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
$HOME/.gradle/gradle.propertiesfile 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?
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
For every release
For clarity these below use Spring Integration git URLs, versions, directories, etc. Replace these values as appropriate.
git clone [[--recursive|git submodule essentials]] email@example.com:SpringSource/spring-integration.gitwhy do a fresh clone?
springIntegrationVersionto the release version, e.g.
GRADLE_OPTS='-XX:MaxPermSize=1024m -Xmx1024m' ./gradlew buildand verify artifacts before publication
git commit -am'Release version 2.1.0.RC2'
git tag v2.1.0.RC2based on best practices for tagging
- Connect to the VPN,
./gradlew uploadArchivesand verify artifacts after publication
springIntegrationVersionto the next development version, e.g.
git commit -am'Update version to 2.1.0.BUILD-SNAPSHOT'
- (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"
git push && git push --tagswhy wait so long to push?