= Release Process =
The following outlines the SasView release process.

== Reminders ==
- The SasView builds can be found here: [http://build.sasview.org/ Windows], [http://download.mantidproject.org/jenkins/view/All/job/sasview_snowleopard_32bit Mac] and [https://builds.sns.gov/view/SasView/ RHEL6].
- The released software is available for download on [http://sourceforge.net/projects/sasview/files/ SourceForge].

== Planning a new major release ==
- Releases are discussed at the bi-weekly meeting. Only planned released are acceptable.
- Once the developers are completely done with their changes and have tested their own code, they should close their ticket and announce it to the rest of the team.
- Once all developers are done with their work, the release will be discussed at the following conference call.
- During that call, a "'''release manager'''" will be appointed for that release. That person is responsible for following the release process below and communicating progress to the team.
- After a release manager has been appointed, a code freeze is declared.

== Testing a new major release ==
- After the code freeze, developers and chosen users will test the release candidate.
- Once everyone agrees that the release candidate is good, the release manager will start the actual release process.

== Preparing a new major release ==
- The release manager will create a release branch (in releases/sasview-x.y.z/) by forking the code from trunk.
- The release manager will make sure that the version number in /releases/sasview-x.y.z/sansview/__init__.py is correct.
- The release manager will update the release build jobs to point to the release branch.
- Once all build jobs successfully build, the release manager will upload the packages to SourceForge, renaming the packages as appropriate.
- The release manager will email the team to announce the release.
- The team will download the new release to make sure it installs.

== Patch releases ==
- Patch release following the procedure outlined above, with the exception that the release candidate is forked by the release manager from the previous major release branch.
- Changes are made directly to the patch release branch so that other developers can continue working on trunk.
- There is no code freeze needed for a patch release.
- Patch releases are for important yet small changes.