Difference between revisions of "Documentation/4.1/Developers/Versioning"

From Slicer Wiki
Jump to: navigation, search
(Prepend documentation/versioncheck template. See http://na-mic.org/Mantis/view.php?id=2887)
 
(31 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
[[Documentation/Versioning|Documentation]]←
+
<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.
  
−
{{ambox|text=This page describe the Slicer versioning scheme}}
+
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/SlicerPackagecript.cmake -VV > /path/to/logs.txt 2>&1
  
−
{{ambox
+
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.
−
| type  = protection
 
−
| image = [[File:InProgress.png|40px|alt=Work in progress]]
 
−
| text  = Page under construction.
 
−
}}
 
  
−
= Slicer package - Naming scheme =
+
= Slicer Package naming scheme =
 +
{{ambox|text=The following information is for Slicer maintainers only}}
  
−
* All packages will have the following root:
+
<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>
−
<pre>Slicer-&lt;MAJOR_VERSION&gt;.&lt;MINOR_VERSION&gt;.&lt;BUILD_VERSION&gt;-&lt;VERSION_SOURCE_OR_RC&gt;-&lt;DATE&gt;-&lt;ARCH&gt;-&lt;PLATFORM&gt;</pre>
 
  
−
* If CTKAppLauncher_VERSION_IS_RELEASE == 0:
+
There are 2 types of builds, releases and developments:
−
<pre>VERSION_SOURCE_OR_RC := g&lt;SHA1&gt;[-dirty]</pre>
+
; Release
−
* else:
+
: Special builds made on a given revision (e.g. r19033: "ENH: Slicer 4.0.1")
−
<pre>VERSION_SOURCE_OR_RC := [-rc{1|2|3...}]</pre>
+
: 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 =
 
= Extension package - Naming scheme =
 +
{{documentation/underconstruction}}
 +
= 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)
 +
* Release commit with message: "ENH: Slicer 4.X.Y"
 +
** In '''Slicer4/CMakeLists.txt''', update <code>Slicer_VERSION_MAJOR</code>, <code>Slicer_VERSION_MINOR</code>, <code>Slicer_VERSION_PATCH</code>. Uncomment and set <code>Slicer_VERSION_TWEAK</code> to 0, <code>Slicer_VERSION_RC</code>...
 +
* commit with message: "ENH: Begin post-4.X.Y development"
 +
** In '''Slicer4/CMakeLists.txt''', comment <code>Slicer_VERSION_TWEAK</code> 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)
 +
*** <code>svn switch http://svn.slicer.org/Slicer4/branches/Slicer-4-1-QtTesting</code>
 +
** update source to release revision
 +
*** <code>cd Slicer; svn update -r19609</code>
 +
** delete build directory to force rebuild
 +
*** <code>cd Slicer-package; rm -rf *</code>
 +
** build, package and upload with cmake
 +
*** <code>cd DashboardScripts; ./factory-make-package.sh</code>
 +
*** make sure LEGACY CLIs is ON, EMSegment needs BSplineToDeformationField.
 +
* Generate ChangeLog using [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
 +
* In Mantis
 +
** "Release" current target
 +
** Create new target
 +
** Check the "fixed in" fields
 +
* Update more recent version on external links:
 +
** on slicer wikipedia article

Latest revision as of 07:26, 14 June 2013

Home < Documentation < 4.1 < 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

 The following information is for Slicer maintainers only 
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

Work in progress
 Page under construction.


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)
  • 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)
    • 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
  • Update more recent version on external links:
    • on slicer wikipedia article
Retrieved from "https://www.slicer.org/w/index.php?title=Documentation/4.1/Developers/Versioning&oldid=32295"