Release Steps

Various documentation changes first (which should be done before the release is cut)

update the scalate_website/src/download.page and scalate_website/src/tool.page pages for this release
edit the scalate_website/src/metainf 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 Rakefile to generate the website to generate the the last version. For example if the last released version is 0.1 then change the line in the Rakefile to…
```
remote /forge/dav/#{project_id}/versions/0.1
```
make sure the CI build for webgen last release runs so that the website for the previous release is archived into the versions directory.
add a link to the versions.page to this old version.

Cutting the release

NOTE make sure you are using a clone of your local git repository for doing the release! See below on the use of temporary local repo…
check your repo is clean and you are on master branch
until ScalaTest releases a version which works with SBT and Scala 2.8.0 you might have to comment the snapshot version in the root pom.xml
prepare the release
```
mvn release:prepare -P release
```
perform the release
```
mvn release:perform -P release
```
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 (the real clone of github) and push changes back to github
```
git rebase --hard
git push
git push origin scalate-project-1.2
```
announce the release on the mailing list

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.2 then do this…
```
git co scalate-project-1.2 -b scalate-1.2.x
git push scalate-1.2.x origin
```
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}
```
edit the scalate last release VCS Root so that it uses the new branch you have just created scalate-project-1.2
until ScalaTest releases a version which works with SBT and Scala 2.8.0 you might have to uncomment the snapshot version in the root pom.xml
ensure that the master branch has its Rakefile to point to the snapshot area
```
remote /forge/dav/#{project_id}/versions/snapshot
```

What all this means is now that you should be able to amend the website for the current release using the scalate-project-1.2 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

Using a temporary local repo

To avoid pushing to the remote repo in experimental attempts at releasing, you can clone your local repo…

git clone file:///foo/scalate scalate-release

You probably want to set this property too if you’re using git 1.6 or later to avoid your release prepare barfing…

git config receive.denycurrentbranch warn

then edit your ~/.m2/settings.xml file and add this…

<settings>
  <profiles> 
    <profile>
      <id>release</id>
      <properties>
        <release-altGitURL>scm:git:file:///foo/scalate</release-altGitURL>
      </properties>
    </profile>
  </profiles>

then perform a release in this new scala-release directory. This will then push to your local repo, not the remote one.

Release Guide

Release Steps

Creating a branch for this release and website changes

Using a temporary local repo