DeploymentProcess

Timestamp:: Oct 7, 2018 11:23:10 PM (6 years ago)
Author:: butler
Comment:: —

Legend:

: Unmodified
: Added
: Removed
: Modified

DevNotes/Processeses/DeploymentProcess

-                      v21
+                      v22
  * If this is a full release, get the Zenodo DOI
  * If this is a full release, update the Zenodo and version number in src/sas/sasview/local_config.py
  * If this release is against a **NEW** version of sasmodels
+ * 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
    * make sure that to update sasmodels.__init__.py to the correct version number
+   * tag HEAD, or the appropriate commit with the release number.
+ * Make sure that the version number is correctly placed in all the appropriate places.  That currently includes:
+   * tag HEAD, or the appropriate commit with the release number. to do so you can either:
+     * Use git to tag HEAD or a commit `$ git tag -a vx.y.z -m "sasmodels version x.y.z"`or
+     * create a release from github. NOTE: creating a `Draft release` will **NOT** create a tag
+ * Make sure that the !SasView version number is correctly placed in all the appropriate places.  That currently includes:
    * 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)
    * /sasview/docs/sphinx-docs/source/user/RELEASE.rst (should have been done as part of updating release notes above)
 …
    * docs/sphinx-docs/source/conf.py (change both version and release numbers)
    * NOTE: sasview.latestversion has now been superseded by the json file stored at the sasview site.
+ * Using instructions published at !GitHub [https://help.github.com/articles/creating-releases/]
+   * Tag sasmodels commit point to be used with this release. 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. Remember to update version number in sasmodels/__init__.py file.
+   * Tag the appropriate !SasView commit point for the release.
+* Using instructions published at !GitHub [https://help.github.com/articles/creating-releases/]
+   * Tag HEAD or the appropriate !SasView commit point for the release. As with sasmodels this can be done either:
+     * Use git to tag HEAD or a commit `$ git tag -a vx.y.z -m "SasView version x.y.z"`or
+     * create a release from github. NOTE: creating a `Draft release` will **NOT** create a tag
    * 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
  * 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.
 …
    * mac: !SasView-V.v.v-MacOSX.dmg
  * An abbreviated version of the  release notes in the README.rst should be entered in the Release Description section.
+ * The documentation folder contents (html version) 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.
+ * The documentation is also built as a PDF and is available on the Jenkins build tab. The PDF should be downloaded as !SasViewDocumentation.pdf from the release build.  The pdf should then be moved to the sasview.github.io repo under downloads (commit and push)
+ * The documentation folder contents (html version) needs to be moved to the sasview.github.io repo under docs.
+  * 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).
+  * git move all the folders and files currently under docs to docs/old_docs/docs_x.y.z
+  * git copy the new html docs (all folders and files) to docs
+    * 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.
+  * commit and push these changes
+* 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.
+ * Again, the first step is to git move the !SasViewDocumentation.pd to downloads/Old_SasViewDoucmentation/
+ * 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.
+ * PDF should be downloaded as !SasViewDocumentation.pdf.
+ * The pdf should then be git copied or git moved to the sasview.github.io/downloads folder.
 == Final release steps ==
  * The release manager will email the team to announce the release process is complete.
  * The team should download the new release to make sure it installs.
+ * The team should download the new release to make sure it installs. Because the release build servers are different than the developer build servers, build server fixes and dependency updates may not have been propagated over to the release server so some rudimentary testing should be done to double check that all is well.
  * Once final approval is given, the release number should be updated in latestversion.json on the !SasView website repo which will alert all !SasView users that a new version is available.