Difference between revisions of "Documentation/4.1/Developers/Versioning"
Revision as of 20:46, 27 February 2012
Home < Documentation < 4.1 < Developers < VersioningContents
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
Slicer Package naming scheme
![]() |
The following information is for Slicer maintainers only |
Slicer-<MAJOR_VERSION>.<MINOR_VERSION>.<PATCH_VERSION>-<TWEAK_VERSION>[-rc{1|2|3...}][-<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
Page under construction. |
To do when versioning
pre release & release
- Update modules documentation link in help section (loadable, scripted and cli)
- Release commit with message: "ENH: Slicer 4.X.Y"
- In Slicer4/CMakeLists.txt, update
Slicer_VERSION_MAJOR
,Slicer_VERSION_MINOR
,Slicer_VERSION_PATCH
,Slicer_VERSION_TWEAK
...
- In Slicer4/CMakeLists.txt, update
- commit with message: "ENH: Begin post-4.X.Y development"
- In Slicer4/CMakeLists.txt, uncomment
Slicer_VERSION_TWEAK
- In Slicer4/CMakeLists.txt, uncomment
post release
- Package machines
- update source to release revision
- build, package and upload with cmake
- Create Slicer-4.[X+1] branch in SlicerVTK
- Make sure all commits are backported into VTK.
- Start from VTK trunk
- Add changelog in http://www.slicer.org/slicerWiki/index.php/Slicer4:QtPort/Releases
- In Mantis
- "Release" current target
- Create new target
- Check the "fixed in" fields