| 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. As a release date approaches the team agrees on what changes/pull requests will be included and which will not. |
| | 10 | * '''Only approved changes should be merged into master from this point till the release.''' All other changes should remain in their branches till after the release. |
| | 11 | * Completed approved changes should be reviewed and then merged to master. NOTE: don't forget to close the relevant tickets upon merging either with the `closes #ticketno` key phrase in the merge notes or manually. |
| | 12 | * Once all approved changes have been merged into master (or is clearly imminent), the release should be discussed at the following conference call. |
| | 13 | * 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 and on Jenkins. |
| 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 | Besides the ongoing testing with every pull request, extra care in testing should be taken for a major release. A first step should be for the developers (and any identified "friendly users" to install the master build from Jenkins and thoroughly test. It is recommended that an actual beta pre-release be published on github to broaden the nunber of testers. |
| | 17 | All bugs and issues identified during this testing phase 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 master build is ready, the release manager will start the final release process. |
| 22 | | * If this is a full release, get the Zenodo DOI |
| 23 | | * If this is a full release, update the Zenodo and version number in src/sas/sasview/local_config.py |
| 24 | | * We should only be using tagged version of sasmodels in a !SasView release unless there is a compelling reason to release from the current sasmodels HEAD. If this release is against a **NEW** version of sasmodels |
| 25 | | * make sure that to update sasmodels.__init__.py to the correct version number |
| 26 | | * tag HEAD, or the appropriate commit with the release number. to do so you can either: |
| 27 | | * Use git to tag HEAD or a commit `$ git tag -a vx.y.z -m "sasmodels version x.y.z"`or |
| 28 | | * create a release from github. NOTE: creating a `Draft release` will **NOT** create a tag |
| 29 | | * Make sure that the !SasView version number is correctly placed in all the appropriate places. That currently includes: |
| 30 | | * src/sas/sasview/local_config.py (where the DOI and vers number go for the about box - should have been done when updating with the Zenodo number above) |
| 31 | | * /sasview/docs/sphinx-docs/source/user/RELEASE.rst (should have been done as part of updating release notes above) |
| 32 | | * src/sas/sasview/_init_.py |
| 33 | | * docs/sphinx-docs/source/conf.py (change both version and release numbers) |
| 34 | | * NOTE: sasview.latestversion has now been superseded by the json file stored at the sasview site. |
| 35 | | * Using instructions published at !GitHub [https://help.github.com/articles/creating-releases/] |
| 36 | | * Tag HEAD or the appropriate !SasView commit point for the release. As with sasmodels this can be done either: |
| | 24 | * Obtain the Zenodo DOI |
| | 25 | * update `src/sas/sasview/_init_.py` with |
| | 26 | * The Zenodo link |
| | 27 | * The new version number |
| | 28 | * The year of the release (used in various copyright notices) |
| | 29 | * When branch changes (mainly release notes) are approved merge the proposed release branch into master - then delete the branch. |
| | 30 | * Tag HEAD or the appropriate !SasView commit point for the release. This can be done either by: |
| 38 | | * create a release from github. NOTE: creating a `Draft release` will **NOT** create a tag |
| 39 | | * 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 |
| | 32 | * create a release from github following instructions published on !GitHub [https://help.github.com/articles/creating-releases/]. NOTE: creating a `Draft release` will **NOT** create a tag |
| | 33 | * 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 |
| | 34 | '''NOTE:''' sasview.latestversion has now been superseded by the json file stored at the sasview site. |
| | 35 | === sasmodels update === |
| | 36 | We should only be using tagged version of sasmodels in a !SasView release unless there is a compelling reason to release from the current sasmodels HEAD. Assuming this release is against a **NEW** version of sasmodels |
| | 37 | * Make sure to update `sasmodels.__init__.py` to the correct version number |
| | 38 | * Tag HEAD, or the appropriate commit with the release number. To do so one can either: |
| | 39 | * Use git to tag HEAD or a commit `$ git tag -a vx.y.z -m "sasmodels version x.y.z"`or |
| | 40 | * Create a release from github following instructions published at !GitHub [https://help.github.com/articles/creating-releases/]. NOTE: creating a `Draft release` will **NOT** create a tag |
| | 41 | |
| | 42 | === Create the Jenkins release builds === |
| 45 | | * An abbreviated version of the release notes in the README.rst should be entered in the Release Description section. |
| 46 | | * The documentation folder contents (html version) needs to be moved to the sasview.github.io repo under docs. |
| 47 | | * The first step it to git create a new folder (docs_x.y.z) under docs/old_docs where x.y.z is the version number being superseded (i.e. the version of the docs currently in the repo). |
| 48 | | * git move all the folders and files currently under docs to docs/old_docs/docs_x.y.z |
| 49 | | * git copy the new html docs (all folders and files) to docs |
| 50 | | * 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. These can just be git copied into the github.io repo folder. |
| 51 | | * commit and push these changes |
| 52 | | * The documentation is also built as a PDF and the PDF link for the website also needs to be updated to the new PDF version. |
| 53 | | * Again, the first step is to git move the !SasViewDocumentation.pd to downloads/Old_SasViewDoucmentation/ |
| 54 | | * The new PDF is available on the Jenkins Master Build tab of the OSX and Ubuntu builds only. **NOTE:** they are **not** currently available in any of the release builds which means they should be downlowded from Mater build immediately after last commits before tagging a release. This should be changed to add a PDF build on the release servers at some point. |
| 55 | | * PDF should be downloaded as !SasViewDocumentation.pdf. |
| 56 | | * The pdf should then be git copied or git moved to the sasview.github.io/downloads folder. |
| 57 | | |
| | 49 | * The portion of the release notes in the RELEASE.rst for this new release version should be entered in the Release Description section (i.e do not copy the full release notes which includes notes for ALL previous versions as well). Also a copy of the ''Acknowledgment and citation'' and ''Bug Reporting'' sections should be included at the end of the Release Description section. |
| | 50 | === update posted documentation === |
| | 51 | Currently we maintain both an html and a PDF copy of the documentation available on the !SasView website. Make sure to follow '''BOTH''' steps below. |
| | 52 | * The documentation folder contents (html version) needs to be moved to the sasview.github.io repo under `/docs`. |
| | 53 | * The first step it to git create a new folder (docs_x.y.z) under `docs/old_docs` where x.y.z is the version number being superseded (i.e. the version of the docs currently in the repo). |
| | 54 | * Git move all the folders and files currently under docs to `docs/old_docs/docs_x.y.z` |
| | 55 | * Git copy the new html docs (all folders and files) to `docs` |
| | 56 | * '''NOTE:''' While the docs could be built locally, for consistency with the release docs it is strongly recommended that the release version be installed locally and the cocs copied from the install path. These can just be git copied into the github.io repo folder. |
| | 57 | * Commit and push these changes |
| | 58 | * The documentation is also built as a PDF and the PDF link for the website also needs to be updated to the new PDF version. |
| | 59 | * Again, the first step is to git move the !SasViewDocumentation.pdf to downloads/Old_SasViewDoucmentation/ |
| | 60 | * The new PDF is available on the Jenkins Master Build tab of the OSX and Ubuntu builds only. **NOTE:** they are **not** currently available in any of the release builds which means they should be downloaded from Mater build immediately after last commits before tagging a release. This should be changed to add a PDF build on the release servers at some point. |
| | 61 | * PDF should be downloaded as !SasViewDocumentation.pdf. |
| | 62 | * The pdf should then be git copied or git moved to the sasview.github.io/downloads folder. |
| | 63 | * Commit and push changes |
