Skip to main content

Tulip Release Process

The goal of this document is to describe the current release process as of February 2011, and propose ameliorations.


Current release process

The current release process (up until the Tulip 3.4 series) was mostly manual.

There were (and still are) automated GUI tests, and some unit tests.

Tulip Binary releases

Windows binaries were built by a hand-written NSIS script.

Mac OS binaries were built manually, and linux releases were handled by the linux distributions.

A major release was decided when there were enough new features, "enough" being subjective to the team's point of view.

Minor releases are supposed to be binary compatible bugfixes.

Plug-ins releases

Plug-ins were generated only at the time of the major release, causing important delays between the time a functionality is implemented, and the time it is delivered to Tulip users.

A good example of this is the lasso interactor, who was redesigned between Tulip 3.4.0 and 3.4.1, adn the new version is still not available on the plug-in server, and, in fact, to anyone using a Tulip not home-compiled.

Proposed release process

The proposed release process relies heavily on continuous integration, with a Jenkins server on at least 2 machines, but preferably 3 or even 4.

* Mac OS X Leopard / Snow leopard (one native, one in VM, or two separate machines)

* Linux host for VMs, one for each important distribution (Ubuntu 8.04 (LTS), Ubuntu 10.04 (LTS), Fedora, ...) and in 32 and 64 bits versions

* Windows XP/7, either on VMs or a separate machine.

A Single Jenkins server would run on one of the machines, and the other machines would run a Jenkins slave, allowing the server to laucnh builds and retrive build artifacts.

Builds would be run nighlty, reporting compiler warnings for GCC, MinGW, Visual Studio, and ideally Clang (which provides intelligible warnings).

CMake is already used as principal build configuration tool, allowing us to use Visual Studio, GCC, and Clang without too much trouble.

Tulip Binary releases

CPack would be used to generate binary packages, as it can generate NSIS scripts, deb files, or Mac OS X installers (which kind we will generate is not clear yet, as some are compatible with Snow Leopard only, but easier, and we want to keep the Leopard users).

As a matter of fact we already have a linux machine dedicated to building Tulip in VMs, and there is a Windows 7x64 machine we can use to build under windows.

This infrastructure would provide us with pain-free nightly builds that could be easily tested by the Tulip community.

Plug-ins releases

The server could re-generate the plug-ins nightly, and updates would be made available to the Tulip users in a matter of hours.

We already have a tool that can generate and publish a plug-in server easily, we would need to have Jenkins call it after building the plug-ins, and the deployment would be effortless.

Other concerns

The fact that different linux distributions use different versions of some libraries can cause problems with binary releases (e.g. we cannot use Qt > 4.2 on Ubuntu 8.04, but some features require Qt >= 4.4), and a solution would be to generate different packages for each distribution.

CPack allows this to be done without too much hurdle, but this still needs some work to be fully working. Getting in touch with the Ubuntu/Fedora/etc community of packagers could help greatly with this, as CPack provides an easy way for them to generate new packages.