| 9 | | - Releases are discussed at the bi-weekly meeting. '''Only planned releases 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. The release manager will need to have release privileges on the repository. |
| 13 | | - After a release manager has been appointed, a code freeze is declared. |
| | 9 | * Releases are discussed at the bi-weekly meeting. '''Only planned releases 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. The release manager will need to have release privileges on the repository. |
| | 13 | * After a release manager has been appointed, a code freeze is declared. |
| 16 | | - After the code freeze, developers and chosen users will test the release candidate. |
| 17 | | - All bugs and issues identified will be ticketed and either fixed or discussed on the conference call to ascertain if they must be fixed (blockers) or can remain known issues to be reported in release notes and fixed in a future release. |
| 18 | | - Once everyone agrees that the release candidate is ready, the release manager will start the final release process. |
| | 16 | * After the code freeze, developers and chosen users will test the release candidate. |
| | 17 | * All bugs and issues identified will be ticketed and either fixed or discussed on the conference call to ascertain if they must be fixed (blockers) or can remain known issues to be reported in release notes and fixed in a future release. |
| | 18 | * Once everyone agrees that the release candidate is ready, the release manager will start the final release process. |
| 21 | | - Update the sasview/README.txt with the latest version release notes |
| 22 | | - Make sure that the version number is correctly placed in all the appropriate places. That currently includes: |
| 23 | | - sasview/_init_.py |
| 24 | | - sasview/README.txt |
| 25 | | - docs/sphinx-docs/source/conf.py (change both version and release numbers) |
| 26 | | - sasview.latestversion has now been superseded by the json file stored at the sasview site. |
| 27 | | - Using instructions published at !GitHub [https://help.github.com/articles/creating-releases/] |
| 28 | | - If necessary tag appropriate sasmodels commit point to be used with this release of !SasView if not using HEAD. |
| 29 | | - Tag the appropriate !SasView commit point for the release if not using HEAD. |
| 30 | | - Note: if decision is made to make a release from an old enough commit point that it is not available on the !GitHub interface the tag can be generated using the local git interface |
| 31 | | - Log into the Jenkins server, navigate to the releases tab and for each platform use "configure" to edit the configuration to use the appropriate sasmodels and !SasView tags for the build. |
| 32 | | - Next, manually launch the Jenkins build processes for each platform being supported. |
| 33 | | - Download the mac and windows builds from the Jenkins build tab and upload the binaries to the releases page. Note that the mac and windows builds will need to be renamed appropriately. Current naming convention is: |
| 34 | | - Windows: setupSasView-V.v.v.exe |
| 35 | | - mac: !SasView-V.v.v-MacOSX.dmg |
| 36 | | - An abbreviated version of the release notes in the README.txt should be entered in the Release Description section. |
| 37 | | - The documentation folder contents needs to be moved to the sasview.github.io repo under docs (commit and push). Currently the release manager can either build the docs locally, but for consistency with the release docs it is strongly recommended that instead they install the release version and copy the docs from the install path. |
| | 21 | * Update the sasview/README.txt with the latest version release notes |
| | 22 | * Make sure that the version number is correctly placed in all the appropriate places. That currently includes: |
| | 23 | * src/sas/sasview/_init_.py |
| | 24 | * installers/README.txt |
| | 25 | * docs/sphinx-docs/source/conf.py (change both version and release numbers) |
| | 26 | * sasview.latestversion has now been superseded by the json file stored at the sasview site. |
| | 27 | * Using instructions published at !GitHub [https://help.github.com/articles/creating-releases/] |
| | 28 | * If necessary tag appropriate sasmodels commit point to be used with this release of !SasView if not using HEAD. |
| | 29 | * Tag the appropriate !SasView commit point for the release if not using HEAD. |
| | 30 | * Note: if decision is made to make a release from an old enough commit point that it is not available on the !GitHub interface the tag can be generated using the local git interface |
| | 31 | * Log into the Jenkins server, navigate to the releases tab and for each platform use "configure" to edit the configuration to use the appropriate sasmodels and !SasView tags for the build. |
| | 32 | * Next, manually launch the Jenkins build processes for each platform being supported. |
| | 33 | * Download the mac and windows builds from the Jenkins build tab and upload the binaries to the releases page. Note that the mac and windows builds will need to be renamed appropriately. Current naming convention is: |
| | 34 | * Windows: setupSasView-V.v.v.exe |
| | 35 | * mac: !SasView-V.v.v-MacOSX.dmg |
| | 36 | * An abbreviated version of the release notes in the README.txt should be entered in the Release Description section. |
| | 37 | * The documentation folder contents needs to be moved to the sasview.github.io repo under docs (commit and push). Currently the release manager can either build the docs locally, but for consistency with the release docs it is strongly recommended that instead they install the release version and copy the docs from the install path. |
| 40 | | - The release manager will email the team to announce the release process is complete. |
| 41 | | - The team should download the new release to make sure it installs. |
| 42 | | - Once final approval is given, the release number will be updated in latestversion.json on the !SasView website repo which will alert all !SasView users that a new version is available. |
| | 40 | * The release manager will email the team to announce the release process is complete. |
| | 41 | * The team should download the new release to make sure it installs. |
| | 42 | * Once final approval is given, the release number will be updated in latestversion.json on the !SasView website repo which will alert all !SasView users that a new version is available. |
| | 43 | |
| | 44 | == Post release steps == |
| | 45 | Once the release is completely done and out, it is recommended that the version numbers in master get updated to the next planned release version number so that developers testing can tell easily tell they are running a post release version. Just the init.py and possibly the sphinx conf.py should be updated at this point. |
| | 46 | |
| | 47 | * src/sas/sasview/_init_.py |
| | 48 | * docs/sphinx-docs/source/conf.py (change both version and release numbers) |
