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

From Slicer Wiki
Jump to: navigation, search
Line 35: Line 35:
 
{{documentation/underconstruction}}
 
{{documentation/underconstruction}}
 
= To do when versioning =
 
= To do when versioning =
 +
== pre release & release ==
 
* Update modules documentation link in help section (loadable, scripted and cli)
 
* Update modules documentation link in help section (loadable, scripted and cli)
 
* Release commit with message: "ENH: Slicer 4.X.Y"
 
* Release commit with message: "ENH: Slicer 4.X.Y"
Line 40: Line 41:
 
* commit with message: "ENH: Begin post-4.X.Y development"  
 
* commit with message: "ENH: Begin post-4.X.Y development"  
 
** In '''Slicer4/CMakeLists.txt''', uncomment <code>Slicer_VERSION_TWEAK</code>
 
** In '''Slicer4/CMakeLists.txt''', uncomment <code>Slicer_VERSION_TWEAK</code>
 +
== post release ==
 
* Package machines
 
* Package machines
 
** update source to release revision
 
** update source to release revision
 
** build, package and upload with cmake
 
** 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
 
* Add changelog in http://www.slicer.org/slicerWiki/index.php/Slicer4:QtPort/Releases
 
* In Mantis
 
* In Mantis

Revision as of 01:42, 25 February 2012

Home < Documentation < 4.1 < Developers < Versioning

Documentation

Slicer Package naming scheme

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


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...
  • commit with message: "ENH: Begin post-4.X.Y development"
    • In Slicer4/CMakeLists.txt, uncomment Slicer_VERSION_TWEAK

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