| | 1 | = Release Process = |
| | 2 | The following outlines the SasView release process. |
| | 3 | |
| | 4 | == Reminders == |
| | 5 | - 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]. |
| | 6 | - The released software is available for download on [http://sourceforge.net/projects/sasview/files/ SourceForge]. |
| | 7 | |
| | 8 | == Planning a new major release == |
| | 9 | - Releases are discussed at the bi-weekly meeting. Only planned released are acceptable. |
| | 10 | - 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. |
| | 11 | - Once all developers are done with their work, the release will be discussed at the following conference call. |
| | 12 | - 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. |
| | 13 | - After a release manager has been appointed, a code freeze is declared. |
| | 14 | |
| | 15 | == Testing a new major release == |
| | 16 | - After the code freeze, developers and chosen users will test the release candidate. |
| | 17 | - Once everyone agrees that the release candidate is good, the release manager will start the actual release process. |
| | 18 | |
| | 19 | == Preparing a new major release == |
| | 20 | - The release manager will create a release branch (in releases/sasview-x.y.z/) by forking the code from trunk. |
| | 21 | - The release manager will make sure that the version number in /releases/sasview-x.y.z/sansview/__init__.py is correct. |
| | 22 | - The release manager will update the release build jobs to point to the release branch. |
| | 23 | - Once all build jobs successfully build, the release manager will upload the packages to SourceForge, renaming the packages as appropriate. |
| | 24 | - The release manager will email the team to announce the release. |
| | 25 | - The team will download the new release to make sure it installs. |
| | 26 | |
| | 27 | == Patch releases == |
| | 28 | - 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. |
| | 29 | - Changes are made directly to the patch release branch so that other developers can continue working on trunk. |
| | 30 | - There is no code freeze needed for a patch release. |
| | 31 | - Patch releases are for important yet small changes. |
