= 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/Other%20Software/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.