View source for Documentation/4.8/Developers/ReleaseProcess

== Release planning ==

Usually ~1 month before release.

<!--
== Prerequisites ==
<small><small>
{{documentation/banner
| text  = These updates should <b>NOT</b> be needed anymore. See details below. }}
</small></small>

Following [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22423 r22423], [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22424 r22424] and [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=25430 r25430] documentation URLs should all reference the <code>Nightly</code> namespace and are automatically updated at runtime.


* <strike>Make sure to patch VS2008 using the script [https://gist.github.com/jcfr/3c7bef3f8b32f9f6ad4b fix-vc9-redist-manifests.ps1]</strike>

{{remark|green|VS2013 is now used}}

* <strike>Update modules documentation link in help section (loadable, scripted and cli)</strike>
** <strike>And some html links in Welcome module (Modules/Loadable/SlicerWelcome/Resources/HTML)</strike> - Not needed since [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=25430 r25430]
** <strike>Update CLI XML description files</strike>
<strike>
Commit message: <code>Update Documentation to X.Y</code>

For example: [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22407 r22407]
</strike>

== Release-candidate ==
<small><small>
{{documentation/banner
| text  = This step is <b>NOT</b> part of our current release process. }}
</small></small>


Since there all development occurs on <code>master</code>, each time version is updated, two commits will be required.

<code><RC></code> corresponds to the release candidate number. It is greater or equal to one.

<ol start="1" style="list-style-type: decimal;">

<li><p>Update the Slicer version information for the release candidate:</p>
<ol style="list-style-type: lower-roman;">
<li><p>In <code>CMakeLists.txt</code>, uncomment and set:</p>
*<code>Slicer_VERSION_TWEAK</code> to <code>0</code>
*<code>Slicer_VERSION_RC</code> to <code><RC></code>
<p>...and if this is the first release candidate, update at least one these variables: <code>Slicer_VERSION_MAJOR</code>, <code>Slicer_VERSION_MINOR</code>, <code>Slicer_VERSION_PATCH</code></p>
</li>
<li>Re-run CMake in order to update <code>Utilities/Scripts/SlicerWizard/__version__.py</code>.</li>
<li><p>Commit the above changes using this message:</p>
 ENH: Slicer X.Y.Z-rc<RC>
</li>
</ol>
</li>

<li>Generate packages based on REVISION associated with step 1.</li>

<li><p>Update the Slicer version information for the development:</p>
<ol style="list-style-type: lower-roman;">
<li>In <code>CMakeLists.txt</code>, comment <code>Slicer_VERSION_TWEAK</code> so that the next builds will contain the date associated with the last commit.</li>
<li>Re-run CMake in order to update <code>Utilities/Scripts/SlicerWizard/__version__.py</code>.</li>
</li>
<li><p>Commit the above changes using this message:</p>
 ENH: Begin post-X.Y.Z-rc<RC> development
</li>
</ol>

</ol>
-->

== Release ==

<!--
<small><small>
{{documentation/banner
| text  = Start here. 
| background-color = 8FBC8F }}
</small></small>
-->

Since there all development occurs on <code>master</code>, each time version is updated, two commits will be required.

<ol start="1" style="list-style-type: decimal;">

<li><p>Update the Slicer version information for the release:</p>
<ol style="list-style-type: lower-roman;">
<li><p>In <code>CMakeLists.txt</code>, update at least one these variables: <code>Slicer_VERSION_MAJOR</code>, <code>Slicer_VERSION_MINOR</code>, <code>Slicer_VERSION_PATCH</code></p>
</li>
<li>
  <p>Re-run CMake in order to update <code>Utilities/Scripts/SlicerWizard/__version__.py</code>.</p>
  <p><small>{{note}}If not doing a clean build, make sure to explicitly specify the version re-configuring with <code>-DSlicer_VERSION_MAJOR:STRING=X -DSlicer_VERSION_MINOR:STRING=Y -DSlicer_VERSION_PATCH:STRING=Z .</code></small></p>
</li>
<li><p>Commit the above changes using this message like:</p>
 ENH: Slicer X.Y.Z
</li>
<li>Keep track of the <tt>SVN_REVISION</tt> and <tt>SVN_BRANCH</tt> for the next steps</li>
</ol>
</li>

<li>Update release scripts. See https://github.com/Slicer/DashboardScripts#rename-and-update-release-scripts</li>

<li>Generate packages running Slicer package scripts and Slicer extensions scripts on each platform. (These are the scripts updated in the previous step)</li>

<li><p>Tag the repository:</p>
SVN:
 svn copy -r<REVISION> http://svn.slicer.org/Slicer4/trunk  \
      http://svn.slicer.org/Slicer4/tags/Slicer-X-Y  \
     -m "ENH: Tag of X.Y.Z release based on r<REVISION>."

GIT:
 git tag -s -m "ENH: Slicer X.Y.Z" vX.Y.Z origin/master
 git push origin vX.Y.Z
</li>

<li><p>Update the Slicer version information for the development:</p>
<ol style="list-style-type: lower-roman;">
<li><p>In <code>CMakeLists.txt</code>,</p>
* Update <code>Slicer_VERSION_MAJOR</code> and/or <code>Slicer_VERSION_MINOR</code>
</li>
<li>
  <p>Re-run CMake in order to update <code>Utilities/Scripts/SlicerWizard/__version__.py</code>.</p>
  <p><small>{{note}}If not doing a clean build, make sure to explicitly specify the version re-configuring with <code>-DSlicer_VERSION_MAJOR:STRING=X -DSlicer_VERSION_MINOR:STRING=Y -DSlicer_VERSION_PATCH:STRING=Z .</code></small></p>
</li>
<li><p>Commit the above changes using this message like:</p>
 ENH: Begin X.Y.Z development
</li>
</ol>
</li>

</ol>

== Post release ==

=== Create a release branch ===

 svn copy -r <REVISION> http://svn.slicer.org/Slicer4/trunk http://svn.slicer.org/Slicer4/branches/Slicer-X-Y \
  -m "ENH: Branching from trunk to Slicer-X-Y at r<REVISION>"


  svn checkout http://svn.slicer.org/Slicer4/branches/Slicer-X-Y

=== Generate ChangeLog ===

* See [https://raw.github.com/cryos/avogadro/master/scripts/gitlog2changelog.py gitlog2changelog.py]. More details [http://blog.cryos.net/archives/202-Git-and-Automatic-ChangeLog-Generation.html here].

* Update [[Release Details]] page using generated ChangeLog

=== Update Mantis ===

* "Release" current target
* Create new target
* Check the "fixed in" fields

=== Midas ===

==== Clean-up older nightly packages ====

See https://gist.github.com/jcfr/ea9ef199bd5a3e071b8f 

==== Tag release packages ====

* If needed, create a X.Y.Z folder in [http://slicer.kitware.com/midas3/folder/274 Slicer/Packages/Application/Release]
** Copy uploaded packages into the folder created above (Keep the default <b>Create a reference to the existing item</b>)
** Identify the item_id associated with uploaded packages. For example: 11926, 11925, 11927, 11992
** From Kitware internal network, SSH connect to <code>jcfr@slicer.kitware.com</code> (or <code>jcfr@192.168.120.210</code>)
** Connect to mysql using <code>mysql -u midas -p</code>
*** See file <code>/var/www/midas3/core/configs/database.local.ini</code> for password
*** Choose midas database: <code>use midas</code>
** List packages associated with identified items and check they are the appropriate ones:
*** <code>select *  from slicerpackages_package as p , item as i where i.item_id = p.item_id and p.item_id in (11926, 11925, 11927, 11992);</code>
** Set release field
*** <code>update slicerpackages_package set `release`="4.2.2-1" where item_id in (11926, 11925, 11927, 11992);</code>

==== Version NA-MIC data tree ====

<ol start="1" style="list-style-type: decimal;">

<li><p>[[Documentation/{{documentation/version}}/Developers/Tutorials/ObtainExtensionServerApiKey|Create an account on the extension server and obtain an API Key]]. You will then use your midas login and api key to substitute <code><YOUR-MIDAS-LOGIN></code> and <code><YOUR-MIDAS-APIKEY></code> in the examples.</p></li>

<li><p>If not already done, go to [http://slicer.kitware.com/midas3/community/23 NA-MIC community] and click on <code>Join community</code></p></li>

<li><p>Send an email on the developer list asking to be added to the <code>DataManager</code> group on NA-MIC community. That will grant you read/write permissions to the <code>Data</code> folder and sub-folders.</p></li>

<li><p>Install prerequisites</p>
<pre>
$ pip install pydas
</pre></li>

<li><p>Identify <code>id</code> of the <code>Data</code> folder. For example [http://slicer.kitware.com/midas3/folder/301 301]</p></li>

<li><p>Simulate creation of <code>X.Y</code> data folders based <code>Nightly</code> ones</p>
<pre>
$ cd /path/to/Slicer/Base/Python/slicer/release
$ python midasdata.py --url=http://slicer.kitware.com/midas3 --data_id=301 \
  --email=<YOUR-MIDAS-LOGIN> --apikey=<YOUR-MIDAS-APIKEY> --source_version=Nightly --dest_version=X.Y --dry-run
Application ( folder_id: 302 )
'-Nightly ( folder_id: 831 )
'-'-Testing ( folder_id: 832 )
'-'-'-Baseline ( folder_id: 889 )
'-'-'-'-DiffusionTensorImagingTutorial.png ( item_id: 12067 )
'-'-'-'-NeurosurgicalPlanningTutorial.png ( item_id: 12066 )
'-'-'-'-SlicerTestingTest.png ( item_id: 17760 )
'-'-'-Input ( folder_id: 833 )
'-'-'-'-AtlasTests ( folder_id: 834 )
'-'-'-'-'-2012-10-26-BrainAtlas.mrb ( item_id: 10276 )
[...]
Module: VotingBinaryHoleFillingImageFilter ( folder_id: 1491 )
'-Nightly ( folder_id: 1491 )
'-'-Testing ( folder_id: 1492 )
'-'-'-Baseline ( folder_id: 1493 )
'-'-'-'-VotingBinaryHoleFillingImageFilterTest.nhdr ( item_id: 103418 )
'-'-'-'-VotingBinaryHoleFillingImageFilterTest.raw.gz ( item_id: 103419 )

</pre>
</li>

<li><p>Create <code>X.Y</code> data tree based <code>Nightly</code> ones</p>
<pre>
$ python midasdata.py --url=http://slicer.kitware.com/midas3 --data_id=301 \
  --email=<YOUR-MIDAS-LOGIN> --apikey=<YOUR-MIDAS-APIKEY> --source_version=Nightly --dest_version=X.Y

Versioning of the NA-MIC Data tree for release X.Y...
Versioning Modules...
[...]
Versioning Modules...[DONE]
Versioning Application...
Creating folder X.Y under Application directory
Duplicating subfolders from Nightly to X.Y...
Duplicating subfolders from Nightly to X.Y...[DONE]
Versioning Application...[DONE]
Versioning of the NA-MIC Data tree for release X.Y...[DONE]

</pre></li>

</ol>

=== Update Slicer wiki ===

There are two steps involved:
* copy of the pages associated with the <code>Nightly</code> namespace into the <code>X.Y</code> namespace.
* update of permanent pages referencing the current Slicer version

As of November 2016, the process is fully automated and can be done using [https://github.com/Slicer/Slicer/tree/master/Base/Python/slicer/release/wiki.py Base/Python/slicer/release/wiki.py] script.

1) Install prerequisites:

* Check with <email>jchris.fillionr@kitware.com</email> to get the credential associated with <code>UpdateBot</code> user.
* Install [https://pypi.python.org/pypi/mwdoc mwdoc]:

<pre>
$ pip install mwdoc
</pre>

2) Query current version information:

<pre>
$ python Base/Python/slicer/release/wiki.py query
</pre>

3) Copy and update pages 

<pre>
$ python Base/Python/slicer/release/wiki.py update 4.6
$ python Base/Python/slicer/release/wiki.py copy 4.6
</pre>

Pages expected to be updated are the following:

* [[Template:Documentation/prevversion]]
* [[Template:Documentation/nextversion]]
* [[Template:Documentation/currentversion]]
* [[Template:Documentation/versionlist]]
* [[Template:Documentation/acknowledgments-versionlist]]
* [[Documentation]]
* [[Documentation/Release/Acknowledgments]]

Pages with #REDIRECT expected to be updated are the following: 

* [[FAQ]]
* [[Documentation/Release]]
* [[Documentation/Release/Announcements]]
* [[Documentation/Release/Report a problem]]
* [[Documentation/UserTraining]]
* [[Documentation/UserFeedback]]
* [[Documentation/Release/SlicerApplication/HardwareConfiguration]]

=== CDash ===

<ol start="1" style="list-style-type: decimal;">
<li><p>Create new CDash groups for extension submissions associated with <code>X.Y</code> release:</p>
<pre>
Extensions-X.Y-Nightly
Extensions-X.Y-Continuous
</pre></li>

</ol>

== ExtensionsIndex ==

See https://github.com/Slicer/ExtensionsIndex

1) Create branch X.Y based of master

=== Update external website ===

* http://en.wikipedia.org/wiki/3DSlicer
* http://www.nitrc.org/projects/slicer/

=== Tag associated projects ===
* Slicer/SlicerExecutionModel
* Slicer/VTK
* Slicer/ITK
* commontk/CTK ?
* commontk/PythonQt ?

=== Update User Survey ===

Title of the survey should be updated.
See https://docs.google.com/forms/d/1rggxoTV5KL_vt3gX9BNNAcKH4pnL5lkMqPnklOThINg

== Sign packages ==

=== MacOSX ===
As discussed in issue [http://na-mic.org/Bug/view.php?id=3965 #3965], the code signing command is of the form:

<pre>
codesign --deep --force --sign "Developer ID Application: <Name-of-certificate-in-keychain>" ./Slicer.app
</pre>

where the argument to <code>--sign</code> is the name of the developer's certificate in Mac OS X Keychain.app .

'''Note: The signing of MacOSX package is not yet implemented in our nightly and release build workflows.''' See [[Documentation/Nightly/Developers/Mac_OS_X_Code_Signing]] for more information.

=== Windows ===

TBD - See [http://na-mic.org/Bug/view.php?id=2697 #2697]

Also see [[Documentation/Nightly/Developers/Windows_Code_Signing]] for more information.

== Backport commit into release branch ==

The following steps will lead to the creation of new git-svn clone having two branches:
* <code>git-svn</code>
* <code>git-svn-XY</code>

Reference: http://www.dmo.ca/blog/20070608113513/

=== Step 1: Checkout sources ===

 git clone git://github.com/Slicer/Slicer.git Slicer-X.Y
 cd Slicer-X.Y
 git svn init http://svn.slicer.org/Slicer4/trunk
 git update-ref refs/remotes/git-svn refs/remotes/origin/master
 git checkout master
 git svn rebase

=== Step 2: Add release branch remote ===

Edit <code>.git/config</code>, and in addition to the existing 'git-svn' remote, add the following one:

 [svn-remote "svn-XY"]
    url = http://svn.slicer.org/Slicer4/branches/Slicer-X-Y
    fetch = :refs/remotes/git-svn-XY

=== Step 3: Pull associated SVN branch ===

 git svn fetch svn-XY
 git checkout -b master-XY git-svn-XY

=== Step 4: Backport ===

We can now cherry pick commit associated with master (trunk) into <code>master-XY</code> (Slicer-X-Y)

=== Step 5: Create a patch release ===

{{wip}}

<!--
Slicer trunk: Update Major/Minor/Patch version to match latest release
-->