Release Steps
Various documentation changes first (which should be done before the release is cut)
- edit the scalate_website/src/main/scala/Website.scala file and change the project_version values
- blog about the release by creating an entry in scalate_website/src/blog/releases
- update the changelog.md file, copying and pasting the section the release highlights from the above blog post
If the release is a major release then we need to freeze the current website at scalate.github.io/scalate/versions/lastVersion
- in the current last-release branch change the scalate-website/pom.xml and edit the “maven-scalate-plugin” section to list the correct remoteServerUrl to something like…
<remoteServerUrl>dav:http://fusesource.com/forge/dav/${forge-project-id}/versions/snapshot
<remoteServerUrl/>
Cutting the release
- check your repo is clean and you are on master branch
- check that we are using the latest versions of dependencies
mvn versions:use-next-releases
mvn versions:update-properties
- then review the changes to pom.xml to check they all seem fine. You probably want to rollback the jetty changes to version 8.x, other than that it should be fine. Do a test run to check!
- Verify that the
src/main/resources/license-header.txt file is still current.
- Check that all the source file license headers are in place:
mvn -P license license:check
mvn -P license license:format
- then review the changes and check they all seem fine. You may need to add exclusions to the
maven-license-plugin's
configuration to ignore some files.
- prepare the release
mvn -P release release:prepare
mvn -P release release:perform
- open Nexus Staging and close the Staging release of scalate
- now Promote the closed release
- now you'll need to tidy up your local repo and push changes back to github
git rebase --hard
git push --tags
- make sure scalate-website/ext/Website.scala has the latest version information.
- update the website (see below on making a branch)
- announce the release on the mailing list
- drink beers!
Creating a branch for this release and website changes
If this is a major release…
- create a branch for this new release. For example if you've just done 1.6.1 then do this…
git co scalate-project-1.6.1 -b scalate-1.6.1.x
git push origin scalate-1.6.1.x
check that this branch generates its website to the main scalate.github.io/scalate location, not scalate.github.io/scalate/versions/snapshot by updating the relevant line in the Rakefile to…
remote /forge/dav/#{project_id}
check that index.page and metainfo have at the correct release number
edit the scalate last release VCS Root so that it uses the new branch you have just created scalate-project-1.6.1
ensure that the master branch has its Rakefile to point to the snapshot area
remote /forge/dav/#{project_id}/versions/snapshot
ensure also that index.page has the new snapshot version number in it
kick off the TeamCity CI build for the scalate last release project
- check the new version appears on the home page
- you might also want to check that the central maven repo has sync'd before announcing
What all this means is now that you should be able to amend the website for the current release using the scalate-project-1.6.1 branch. You can also document new upcoming features for the next release which go into the master branch which should be auto-deployed to the snapshot website
- clone the scalate homebrew repo if you've not done so yet
- hack the Library/Formula/scalate.rb file in the usual homebrew way
- zap the md5 from /usr/local/Library/Formula/scalate.rb
- edit the version number in the formula
- run the following command
- fill in the md5
- check the install worked
- copy the scalate.rb into your Library/Formula of your homebrew clone
