Difference between revisions of "Documentation/Nightly/Developers/ReleaseProcess"
Line 318: | Line 318: | ||
See https://docs.google.com/forms/d/1rggxoTV5KL_vt3gX9BNNAcKH4pnL5lkMqPnklOThINg | See https://docs.google.com/forms/d/1rggxoTV5KL_vt3gX9BNNAcKH4pnL5lkMqPnklOThINg | ||
− | + | == Sign packages == | |
− | + | === MacOSX === | |
As discussed in issue [http://na-mic.org/Bug/view.php?id=3965 #3965], the code signing command is of the form: | As discussed in issue [http://na-mic.org/Bug/view.php?id=3965 #3965], the code signing command is of the form: | ||
Line 331: | Line 331: | ||
'''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. | '''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 [http://na-mic.org/Bug/view.php?id=2697 #2697] | TBD - See [http://na-mic.org/Bug/view.php?id=2697 #2697] | ||
Line 337: | Line 337: | ||
Also see [[Documentation/Nightly/Developers/Windows_Code_Signing]] for more information. | 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: | The following steps will lead to the creation of new git-svn clone having two branches: | ||
Line 345: | Line 345: | ||
Reference: http://www.dmo.ca/blog/20070608113513/ | Reference: http://www.dmo.ca/blog/20070608113513/ | ||
− | + | === Step 1: Checkout sources === | |
git clone git://github.com/Slicer/Slicer.git Slicer-X.Y | git clone git://github.com/Slicer/Slicer.git Slicer-X.Y | ||
Line 354: | Line 354: | ||
git svn rebase | git svn rebase | ||
− | + | === Step 2: Add release branch remote === | |
Edit <code>.git/config</code>, and in addition to the existing 'git-svn' remote, add the following one: | Edit <code>.git/config</code>, and in addition to the existing 'git-svn' remote, add the following one: | ||
Line 362: | Line 362: | ||
fetch = :refs/remotes/git-svn-XY | fetch = :refs/remotes/git-svn-XY | ||
− | + | === Step 3: Pull associated SVN branch === | |
git svn fetch svn-XY | git svn fetch svn-XY | ||
git checkout -b master-XY git-svn-XY | git checkout -b master-XY git-svn-XY | ||
− | + | === Step 4: Backport === | |
We can now cherry pick commit associated with master (trunk) into <code>master-XY</code> (Slicer-X-Y) | We can now cherry pick commit associated with master (trunk) into <code>master-XY</code> (Slicer-X-Y) | ||
− | + | === Step 5: Create a patch release === | |
{{wip}} | {{wip}} |
Revision as of 05:00, 18 October 2017
Home < Documentation < Nightly < Developers < ReleaseProcessContents
Release planning
Usually ~1 month before release.
Release
Since there all development occurs on master
, each time version is updated, two commits will be required.
Update the Slicer version information for the release:
In
CMakeLists.txt
, update at least one these variables:Slicer_VERSION_MAJOR
,Slicer_VERSION_MINOR
,Slicer_VERSION_PATCH
-
Re-run CMake in order to update
Utilities/Scripts/SlicerWizard/__version__.py
.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 .
Commit the above changes using this message like:
ENH: Slicer X.Y.Z
- Keep track of the SVN_REVISION and SVN_BRANCH for the next steps
- Update release scripts. See https://github.com/Slicer/DashboardScripts#rename-and-update-release-scripts
- Generate packages running Slicer package scripts and Slicer extensions scripts on each platform. (These are the scripts updated in the previous step)
Tag the repository:
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:
git tag -s -m "ENH: Slicer X.Y.Z" vX.Y.Z origin/master git push origin vX.Y.Z
Update the Slicer version information for the development:
In
CMakeLists.txt
,- Update
Slicer_VERSION_MAJOR
and/orSlicer_VERSION_MINOR
- Update
-
Re-run CMake in order to update
Utilities/Scripts/SlicerWizard/__version__.py
.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 .
Commit the above changes using this message like:
ENH: Begin X.Y.Z development
Post release
Create a release branch
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
Generate ChangeLog
- See gitlog2changelog.py. More details here.
- Update Release Details page using generated ChangeLog
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
(orjcfr@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
- See file
- 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
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.If not already done, go to NA-MIC community and click on
Join community
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 theData
folder and sub-folders.Install prerequisites
$ pip install pydas
Identify
id
of theData
folder. For example 301Simulate creation of
X.Y
data folders basedNightly
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 )
Create
X.Y
data tree basedNightly
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 theX.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:
- Template:Documentation/prevversion
- Template:Documentation/nextversion
- Template:Documentation/currentversion
- Template:Documentation/versionlist
- Template:Documentation/acknowledgments-versionlist
- Documentation
- Documentation/Release/Acknowledgments
Pages with #REDIRECT expected to be updated are the following:
- FAQ
- Documentation/Release
- Documentation/Release/Announcements
- Documentation/Release/Report a problem
- Documentation/UserTraining
- Documentation/UserFeedback
- Documentation/Release/SlicerApplication/HardwareConfiguration
CDash
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
Tag associated projects
- Slicer/SlicerExecutionModel
- Slicer/VTK
- Slicer/ITK
- commontk/CTK ?
- commontk/PythonQt ?
Update User Survey
Title of the survey should be updated. See https://docs.google.com/forms/d/1rggxoTV5KL_vt3gX9BNNAcKH4pnL5lkMqPnklOThINg
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)
Step 5: Create a patch release