Difference between revisions of "QtAugust2010/Deployment Process"
| Line 7: | Line 7: | ||
** So on 7-22, for example, the svn # will be 15434 for all versions of the nightly build. The 'files changed' line at the top of the dashboard will reflect the changes since the equivalent on 7-21. etc. | ** So on 7-22, for example, the svn # will be 15434 for all versions of the nightly build. The 'files changed' line at the top of the dashboard will reflect the changes since the equivalent on 7-21. etc. | ||
* We need to pay more attention to windows. | * We need to pay more attention to windows. | ||
| + | |||
| + | =Current Situation= | ||
| + | see here http://www.slicer.org/slicerWiki/index.php/Slicer3:Builds | ||
= Regarding packaging = | = Regarding packaging = | ||
Revision as of 17:29, 23 July 2010
Home < QtAugust2010 < Deployment ProcessSlicer Deployment
Proposed user-experience for releasing slicer executables and modules:
- Slicer executables will be downloaded from the Slicer website. This will include .exe for windows, .dmg for mac and .rpm .deb for linux. We will have 32 and 64 bit versions. There will be a second URL for mirroring. The same will be the case for those extensions, which can be installed from within Slicer using the extension manager.
- The Slicer dashboards will show and identify the machines which are used to compile the downloadable slicer executables. The SVN numbers (or the git equivalent) for the day will be the same for all versions of Slicer executables and the plugins and will be in sync with the updates on the dashboard.
- So on 7-22, for example, the svn # will be 15434 for all versions of the nightly build. The 'files changed' line at the top of the dashboard will reflect the changes since the equivalent on 7-21. etc.
- We need to pay more attention to windows.
Current Situation
see here http://www.slicer.org/slicerWiki/index.php/Slicer3:Builds
Regarding packaging
Stay with .tar.gz for linux, built on an old but widely used linux kernel. The rationale is that the .deb and .rpm options really on make sense when they are distributed by the distribution maintainer (i.e. debian or fedora) because they end up being very dependent on the particular release configuration. So we should work instead to get our code into their build streams, with the knowledge that there will be a lag for introducing new versions. For 'typical' linux users (if there is such a thing) our story would then be:
- install the version for your distro (i.e. 'apt-get install slicer' as in current debian) if this is not up-to-date enough go to step 2
- download the tar.gz version. Probably this will work fine with your kernel and libraries. if not, go to step 3
- build from source using superbuild.
Only a very small group will end up at step 3. And realistically building code on linux is not /that/ hard for a linux user -- or should I say, being a linux user is almost as hard as building code :)
