Changes between Version 3 and Version 4 of DevNotes/Processeses/DeploymentProcess

Timestamp:

Oct 18, 2015 7:20:05 PM (9 years ago)

Author:

butler

Comment:

—

DevNotes/Processeses/DeploymentProcess

@@ -3 +3 @@
 
 == 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/SasView/ RHEL6].
-- The released software is available for download on [http://sourceforge.net/projects/sasview/files/ SourceForge].
+- The SasView builds can be found here: [https://jenkins.esss.dk/sasview/view/Master-Builds/]. Note we are not releasing Unix versions at this time despite the Ubuntu build machine.
+- The released software is available for download on [https://github.com/SasView/sasview/releases !GitHub].
 
 == Planning a new major release ==
@@ -10 +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.
 - 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.
+- 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 priviledges on the repository.
 - 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.
+- 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.
+- Once everyone agrees that the release candidate is ready, 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 [https://sourceforge.net/projects/sasview/files/ SourceForge], renaming the packages as appropriate.
-- The release notes (README.txt) should also be copied to Sourceforge so that they appear on the download page.
+- The release manager will make sure that the version number is correctly placed in all the correct places.  That currently includes:
+-- sasview/__init__.py
+-- sasview/README.txt
+-- docs/sphynx-docs/source/conf.py (change both version and release numbers)
+-- sasview.latestversion has now been superseded by the json file stored at the sasview site.
+- The release manager will download the mac and windows builds from the build site.
+- The release manager will then tag the current repo for release and execute the release process as described at [https://help.github.com/articles/creating-releases/]. Note that the mac and windows builds will need to be renamed appropriately and uploaded as binaries along with the .
+- An abbreviated version of the  release notes in the README.txt should be entered in the Release Description section.
 - 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.
+- Currently patch releases follow the same process as major releases but the cycle is usually much abbreviated.