View source for Documentation/4.3/Developers/Versioning

<noinclude>{{documentation/versioncheck}}</noinclude>
<!-- 
= How to create a Slicer package =

== Locally on your machine ==

After Slicer correctly build and test, to create a binary package on mac/unix:

 $ cd Slicer-Superbuild/Slicer-build
 $ make package

For Visual Studio on Windows, the inner Slicer (not superbuild) solution file contains a 'PACKAGE' project, just build it. You might have to install [http://nsis.sourceforge.net/Download NSIS] prior.

On Mac OS X, a 'dmg' file is generated, on unix it's a tar.gz archive and on Windows it's a exe installer.

== Automatically expose it to the Slicer community ==

CTest can automatically create a package and upload it on [http://slicer.cdash.org slicer.cdash.org] and [http://download.slicer.org download.slicer.org] to be available to the community.

You need to create a script following the template [http://viewvc.slicer.org/viewvc.cgi/Slicer4/trunk/CMake/SlicerDashboardScript.TEMPLATE.cmake?view=markup Slicer/CMake/SlicerDashboardScript.TEMPLATE.cmake]. Change the following variables <code>WITH_PACKAGES</code> to <code>TRUE</code> and <code>SCRIPT_MODE</code> to <code>experimental</code> 

Then you can run your script:
 $ ctest -S /path/to/SlicerPackageScript.cmake -VV > /path/to/logs.txt 2>&1

Please note that the source and build directories should not be located in '''/usr'''. The libraries would be considered by the packaging mechanism as "system" libraries.
-->


= Versioning =

== Project fork ==

While Slicer specific patches related to dependent project (i.e. VTK) are integrated upstream, it is not uncommon to build Slicer against a Slicer specific fork of the project.

For example: https://github.com/Slicer/VTK

=== Patches for tagged release ===

For each version of the project requiring some specific patches, a branch following that convention will be created: <code>slicer-vX.Y.Z</code> where <code>X.Y.Z</code> corresponds to the version of the project.

For example, in case of the SlicerVTK fork, the branch <code>slicer-v5.10.1</code> has been created.

=== Patches for development branch ===

In this case, since there is no tag associated with the branch, the Slicer specific patch should be added to a branch named using the date of the commit parent of the Slicer branch: <code>slicer-YEAR-MONTH-DAY-vX.Y</code> where <code>X.Y</code> corresponds to the fork release.

== Create release dashboard scripts ==

{{wip}}

== Feature freeze ==

Usually ~1 month before release.

== Prerequisites ==

* Update modules documentation link in help section (loadable, scripted and cli)
** And some html links in Welcome module (Modules/Loadable/SlicerWelcome/Resources/HTML)
** Update CLI XML description files

Commit message: <code>Update Documentation to X.Y</code>

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

== Release-candidate ==

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>In <code>CMakeLists.txt</code>, uncomment and set:
*<code>Slicer_VERSION_TWEAK</code> to <code>0</code>
*<code>Slicer_VERSION_RC</code> to <code>1</code>, <code>2</code> or <code>3</code></p>

<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><p>Commit <code>CMakeLists.txt</code> changes using this message:</p><pre>ENH: Slicer X.Y.Z-rc<RC></pre></li>

<li><p>Generate packages based on REVISION associated with step1.</p></li>

<li>
<p>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.</p>
</li>

<li>
<p>Commit <code>CMakeLists.txt</code> changes using this message:</p> <pre>ENH: Begin post-X.Y.Z-rc<RC> development</pre>
</li>

</ol>

== Release ==

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>In <code>CMakeLists.txt</code>, uncomment and set <code>Slicer_VERSION_TWEAK</code> to <code>0</code></p>

<p>... and if this no release candidate has been made, 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>Commit <code>CMakeLists.txt</code> changes using this message:</p><pre>ENH: Slicer X.Y.Z</pre></li>

<li>
 <p>Generate packages based on REVISION associated with step1.</p>
 <p>Tag the repository:</p>
 <pre>
  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>."
 </pre>
</li>

<li><p>In <code>CMakeLists.txt</code>, comment and set:</p>
* <code>Slicer_VERSION_TWEAK</code> to <code>0</code> so that the next builds will contain the date associated with the last commit.
* <code>Slicer_VERSION_RC</code> to <code>0</code>
</li>

<li><p>Commit <code>CMakeLists.txt</code> changes using this message:</p> <pre>ENH: Begin post-X.Y.Z development</pre></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

=== Backport commit into release branch ===

The following steps will lead to the creation of new git-svn clone having to branch:
* <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 git-svn-XY -r <REVISION>
 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
-->

=== 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 ===

==== 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
** Identify the item_id associated with uploaded packages. For example: 11926, 11925, 11927, 11992
** SSH connect to <code>jcfr@slicer.kitwarein.com</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>
$ sudo 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 ===

The copy of the pages associated with the <code>Nightly</code> namespace into the <code>X.Y</code> namespace is done using the convenience python module [https://github.com/jcfr/mwdoc#readme mwdoc].

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

<li><p>Check with <email>jchris.fillionr@kitware.com</email> to get the credential associated with <code>UpdateBot</code> user.</p></li>

<li>
  <p>Copy <code>Nightly</code> pages into <code>X.Y</code> pages.</p>
  <pre>
$ cd ~/Projects

$ sudo pip install mwclient

$ git clone git://github.com/jcfr/mwdoc

$ cd mwdoc

$ python

>>> import mwdoc
>>> doc = mwdoc.Documentation('slicer.org', '/slicerWiki/')
>>> doc.login('UpdateBot', 'XXXXXXX')
>>> doc.versionPages('Nightly', '4.3', ['Documentation', 'Template:Documentation'])
[INFO] Page successfully created: 'Documentation/4.3/Extensions/ErodeDilateLabel'
[...]

  </pre>
</li>

</ol>

=== Update external website ===

See http://en.wikipedia.org/wiki/3DSlicer

= Slicer Package naming scheme =
{{ambox|text=The following information is for Slicer maintainers only}}

<pre>Slicer-&lt;MAJOR_VERSION&gt;.&lt;MINOR_VERSION&gt;.&lt;PATCH_VERSION&gt;[-rc{1|2|3...}][-&lt;TWEAK_VERSION&gt;][-&lt;DATE&gt;][-svn&lt;REV&gt;][-dirty]-&lt;ARCH&gt;-&lt;PLATFORM&gt;</pre>

There are 2 types of builds, releases and developments:
; Release
: Special builds made on a given revision (e.g. r19033: "ENH: Slicer 4.0.1")
: Don't contain date or revision number.
: The optional suffix '''-rc{1|2|3|...}''' identifies the release candidates leading to a final release.
: Eventually, a tweak number can be added (e.g. 4.0.1-1)
; Development
: Nightly or experimental builds
: Contains suffixes after the major.minor.patch version 
: The suffix '''svn&lt;REV&gt;''' allows to identify the revision associated with the current package.
: The '''-dirty''' prefix indicates if the package has been generated from a locally modified source tree.

== Example of linux 64bits packages ==
 [              File name               ][   date   ][ build type ][                      note                     ]
 Slicer-4.0.0-linux-amd64                 2011-11-24    release     release of Slicer 4.0.0
 Slicer-4.0.0-2011-12-10-linux-amd64      2011-11-25  development   nightly build after 4.0.0
 Slicer-4.0.1-rc1-linux-amd64             2012-01-04    release     release candidate 1 of Slicer 4.0.1
 Slicer-4.0.1-rc1-2012-01-05-linux-amd64  2012-01-05  development   nightly build after the release candidate
 Slicer-4.0.1-rc2-linux-amd64             2012-01-11    release     release candidate 2 of Slicer 4.0.1
 Slicer-4.0.1-rc2-2012-01-12-linux-amd64  2012-01-12  development   nightly build after the release candidate
 Slicer-4.0.1-linux-amd64                 2012-01-14    release     release of Slicer 4.0.1
 Slicer-4.0.1-2012-01-20-linux-amd64      2012-01-20  development   nightly build after 4.0.1
 Slicer-4.0.1-1-linux-amd64               2012-01-28    release     tweak version 1 of Slicer 4.0.1
 Slicer-4.0.2-linux.amd64                 2012-06-05    release     release of Slicer 4.0.2

= Extension package - Naming scheme =

* Create <code>Extensions-XYZ-Nightly</code> and <code>Extensions-XYZ-Continuous</code> tracks on CDash

*