Documentation/4.2/Developers/Versioning

For the latest Slicer documentation, visit the read-the-docs.

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 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 slicer.cdash.org and download.slicer.org to be available to the community.

You need to create a script following the template Slicer/CMake/SlicerDashboardScript.TEMPLATE.cmake. Change the following variables WITH_PACKAGES to TRUE and SCRIPT_MODE to experimental

Then you can run your script:

$ ctest -S /path/to/SlicerPackagecript.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.

Slicer Package naming scheme

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

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<REV> 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 Extensions-XYZ-Nightly and Extensions-XYZ-Continuous tracks on CDash

To do when versioning

At feature freeze (~1 month before release)

• Create Slicer-4.[X+1] branch in SlicerVTK
  • Make sure all commits are backported into VTK.
  • Start from official VTK release branch or trunk (not recommanded)
  • Try slicer with no Slicer.ini

pre release & release

• 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
• Release commit with message: "ENH: Slicer 4.X.Y"
  • In Slicer4/CMakeLists.txt, update Slicer_VERSION_MAJOR, Slicer_VERSION_MINOR, Slicer_VERSION_PATCH. Uncomment and set Slicer_VERSION_TWEAK to 0, Slicer_VERSION_RC...
• commit with message: "ENH: Begin post-4.X.Y development"
  • In Slicer4/CMakeLists.txt, comment Slicer_VERSION_TWEAK so the next builds will contain the day of build.

post release

• Package machines
  • switch to branch (make sure at least you are on trunk otherwise)
    • svn switch http://svn.slicer.org/Slicer4/branches/Slicer-4-1-QtTesting
  • update source to release revision
    • cd Slicer; svn update -r19609
  • delete build directory to force rebuild
    • cd Slicer-package; rm -rf *
  • build, package and upload with cmake
    • cd DashboardScripts; ./factory-make-package.sh
    • make sure LEGACY CLIs is ON, EMSegment needs BSplineToDeformationField.
• Generate ChangeLog using gitlog2changelog.py. More details here .
• Update Release Details page using generated ChangeLog
• In Mantis
  • "Release" current target
  • Create new target
  • Check the "fixed in" fields