Difference between revisions of "Documentation/Nightly/Developers/ReleaseProcess"

From Slicer Wiki
Jump to: navigation, search
Line 5: Line 5:
 
* Define a release date
 
* Define a release date
 
* Announce the release: https://discourse.slicer.org/t/upcoming-slicer-4-8-release/1120
 
* Announce the release: https://discourse.slicer.org/t/upcoming-slicer-4-8-release/1120
 
<!--
 
== Prerequisites ==
 
<small><small>
 
{{documentation/banner
 
| text  = These updates should <b>NOT</b> be needed anymore. See details below. }}
 
</small></small>
 
 
Following [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22423 r22423], [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22424 r22424] and [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=25430 r25430] documentation URLs should all reference the <code>Nightly</code> namespace and are automatically updated at runtime.
 
 
 
* <strike>Make sure to patch VS2008 using the script [https://gist.github.com/jcfr/3c7bef3f8b32f9f6ad4b fix-vc9-redist-manifests.ps1]</strike>
 
 
{{remark|green|VS2013 is now used}}
 
 
* <strike>Update modules documentation link in help section (loadable, scripted and cli)</strike>
 
** <strike>And some html links in Welcome module (Modules/Loadable/SlicerWelcome/Resources/HTML)</strike> - Not needed since [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=25430 r25430]
 
** <strike>Update CLI XML description files</strike>
 
<strike>
 
Commit message: <code>Update Documentation to X.Y</code>
 
 
For example: [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22407 r22407]
 
</strike>
 
 
== Release-candidate ==
 
<small><small>
 
{{documentation/banner
 
| text  = This step is <b>NOT</b> part of our current release process. }}
 
</small></small>
 
 
 
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>Update the Slicer version information for the release candidate:</p>
 
<ol style="list-style-type: lower-roman;">
 
<li><p>In <code>CMakeLists.txt</code>, uncomment and set:</p>
 
*<code>Slicer_VERSION_TWEAK</code> to <code>0</code>
 
*<code>Slicer_VERSION_RC</code> to <code><RC></code>
 
<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>Re-run CMake in order to update <code>Utilities/Scripts/SlicerWizard/__version__.py</code>.</li>
 
<li><p>Commit the above changes using this message:</p>
 
ENH: Slicer X.Y.Z-rc<RC>
 
</li>
 
</ol>
 
</li>
 
 
<li>Generate packages based on REVISION associated with step 1.</li>
 
 
<li><p>Update the Slicer version information for the development:</p>
 
<ol style="list-style-type: lower-roman;">
 
<li>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.</li>
 
<li>Re-run CMake in order to update <code>Utilities/Scripts/SlicerWizard/__version__.py</code>.</li>
 
</li>
 
<li><p>Commit the above changes using this message:</p>
 
ENH: Begin post-X.Y.Z-rc<RC> development
 
</li>
 
</ol>
 
 
</ol>
 
-->
 
  
 
== Release ==
 
== Release ==
 
<!--
 
<small><small>
 
{{documentation/banner
 
| text  = Start here.
 
| background-color = 8FBC8F }}
 
</small></small>
 
-->
 
  
 
Since there all development occurs on <code>master</code>, each time version is updated, two commits will be required.
 
Since there all development occurs on <code>master</code>, each time version is updated, two commits will be required.

Revision as of 18:30, 18 October 2017

Home < Documentation < Nightly < Developers < ReleaseProcess

Release planning

Release

Since there all development occurs on master, each time version is updated, two commits will be required.

  1. Update the Slicer version information for the release:

    1. In CMakeLists.txt, update at least one these variables: Slicer_VERSION_MAJOR, Slicer_VERSION_MINOR, Slicer_VERSION_PATCH

    2. Re-run CMake with -DSlicer_RELEASE_TYPE:STRING=Stable. This is required to update Utilities/Scripts/SlicerWizard/__version__.py.

      Note If not doing a clean build, make sure to explicitly specify the version re-configuring with -DSlicer_VERSION_MAJOR:STRING=X -DSlicer_VERSION_MINOR:STRING=Y -DSlicer_VERSION_PATCH:STRING=Z .

    3. Commit the above changes using this message like:

      ENH: Slicer X.Y.Z
      
    4. Keep track of the SVN_REVISION and SVN_BRANCH for the next steps
  2. Update release scripts. See https://github.com/Slicer/DashboardScripts#rename-and-update-release-scripts
  3. Generate packages running Slicer package scripts and Slicer extensions scripts on each platform. (These are the scripts updated in the previous step)
  4. Tag the repository:

    SVN (Keep track of the branch revision. It will be referred below as BRANCHED_REVISION.):

    cd ~/Projects
    svn checkout http://svn.slicer.org/Slicer4/trunk Slicer-X.Y-SVN
    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>."
    

    GIT:

    cd ~/Projects
    git clone git@github.com:Slicer/Slicer Slicer-X.Y
    git tag -s -m "ENH: Slicer X.Y.Z" vX.Y.Z origin/master
    git push origin vX.Y.Z
    
  5. Create release branch:

    SVN:

    cd ~/Projects/Slicer-X.Y-SVN
    svn copy -r <REVISION> http://svn.slicer.org/Slicer4/trunk http://svn.slicer.org/Slicer4/branches/Slicer-X-Y \
        -m "ENH: Branching from trunk to Slicer-X-Y at r<REVISION>"
    
    svn checkout http://svn.slicer.org/Slicer4/branches/Slicer-X-Y
    

    GIT:

     cd ~/Projects/Slicer-X.Y
     
     # Source: http://ivanz.com/2009/01/15/selective-import-of-svn-branches-into-a-gitgit-svn-repository/
     # and https://stackoverflow.com/questions/19712735/git-svn-cannot-setup-tracking-information-starting-point-is-not-a-branch
     
     git config --add svn-remote.svn-XY.url http://svn.slicer.org/Slicer4/branches/Slicer-X-Y
     git config --add svn-remote.svn-XY.fetch :refs/remotes/git-svn-XY
     
     git svn fetch svn-XY -r BRANCHED_REVISION
     
     git checkout -b master-XY remotes/git-svn-XY
     
     git svn rebase
     
     git push origin master-XY
    
  6. Update Release Details with release information
  7. Update the Slicer version information for the development:

    1. In CMakeLists.txt,

      • Update Slicer_VERSION_MAJOR and/or Slicer_VERSION_MINOR
    2. Re-run CMake with -DSlicer_RELEASE_TYPE:STRING=Experimental. This is required to update Utilities/Scripts/SlicerWizard/__version__.py.

      Note If not doing a clean build, make sure to explicitly specify the version re-configuring with -DSlicer_VERSION_MAJOR:STRING=X -DSlicer_VERSION_MINOR:STRING=Y -DSlicer_VERSION_PATCH:STRING=Z .

    3. Commit the above changes using this message like:

      cd ~/Projects/Slicer
      git add -A
      git commit -m "ENH: Begin X.Y.Z development"
      

Post release

Update Mantis

  • "Release" current target
  • Create new target
  • Check the "fixed in" fields

Midas

Clean-up older nightly packages

See https://gist.github.com/jcfr/ea9ef199bd5a3e071b8f

Tag release packages

  • If needed, create a X.Y.Z folder in Slicer/Packages/Application/Release
    • Copy uploaded packages into the folder created above (Keep the default Create a reference to the existing item)
    • Identify the item_id associated with uploaded packages. For example: 11926, 11925, 11927, 11992
    • From Kitware internal network, SSH connect to jcfr@slicer.kitware.com (or jcfr@192.168.120.210)
    • Connect to mysql using mysql -u midas -p
      • See file /var/www/midas3/core/configs/database.local.ini for password
      • Choose midas database: use midas
    • List packages associated with identified items and check they are the appropriate ones:
      • 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);
    • Set release field
      • update slicerpackages_package set `release`="4.2.2-1" where item_id in (11926, 11925, 11927, 11992);

Version NA-MIC data tree

  1. Create an account on the extension server and obtain an API Key. You will then use your midas login and api key to substitute <YOUR-MIDAS-LOGIN> and <YOUR-MIDAS-APIKEY> in the examples.

  2. If not already done, go to NA-MIC community and click on Join community

  3. Send an email on the developer list asking to be added to the DataManager group on NA-MIC community. That will grant you read/write permissions to the Data folder and sub-folders.

  4. Install prerequisites

    $ pip install pydas
    
  5. Identify id of the Data folder. For example 301

  6. Simulate creation of X.Y data folders based Nightly ones

    $ 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 )
    
    
  7. Create X.Y data tree based Nightly ones

    $ 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]
    
    

Update Slicer wiki

There are two steps involved:

  • copy of the pages associated with the Nightly namespace into the X.Y namespace.
  • update of permanent pages referencing the current Slicer version

As of November 2016, the process is fully automated and can be done using Base/Python/slicer/release/wiki.py script.

1) Install prerequisites:

  • Check with <email>jchris.fillionr@kitware.com</email> to get the credential associated with UpdateBot user.
  • Install mwdoc:
$ pip install mwdoc

2) Query current version information:

$ python Base/Python/slicer/release/wiki.py query

3) Copy and update pages

$ python Base/Python/slicer/release/wiki.py update 4.6
$ python Base/Python/slicer/release/wiki.py copy 4.6

Pages expected to be updated are the following:

Pages with #REDIRECT expected to be updated are the following:

CDash

  1. Create new CDash groups for extension submissions associated with X.Y release:

    Extensions-X.Y-Nightly
    Extensions-X.Y-Continuous
    

ExtensionsIndex

See https://github.com/Slicer/ExtensionsIndex

1) Create branch X.Y based of master

Update external website


Update User Survey (Not Needed Anymore)

Title of the survey should be updated. See https://docs.google.com/forms/d/1rggxoTV5KL_vt3gX9BNNAcKH4pnL5lkMqPnklOThINg

Instead, the Slicer welcome module has been updated to ask user to report feedback on the Slicer forum

Sign packages

MacOSX

As discussed in issue #3965, the code signing command is of the form:

codesign --deep --force --sign "Developer ID Application: <Name-of-certificate-in-keychain>" ./Slicer.app

where the argument to --sign is the name of the developer's certificate in Mac OS X Keychain.app .

Note: The signing of MacOSX package is not yet implemented in our nightly and release build workflows. See Documentation/Nightly/Developers/Mac_OS_X_Code_Signing for more information.

Windows

TBD - See #2697

Also see Documentation/Nightly/Developers/Windows_Code_Signing for more information.

Backport commit into release branch

The following steps will lead to the creation of new git-svn clone having two branches:

  • git-svn
  • git-svn-XY

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 .git/config, 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 svn-XY
git checkout -b master-XY git-svn-XY

Step 4: Backport

We can now cherry pick commit associated with master (trunk) into master-XY (Slicer-X-Y)