Define rolling release procedure and tools for BrainVISA

[sapetnioc]

To date a BrainVISA release is composed of many components, each on being in a GitHub project with it own version, that are put together in a release with a global version. We want to be able to release components independently whenever an important change has to be published. For this there are three difficulties to take into account:

1. There are too many components and, therefore, too many versions to manage. It had been decided to group these components in order to create Conda packages. Therefore, a conda package with a single version can be composed of several components with possibly different versions. To make things simple and to be able to do classical BrainVISA releases in parallel of Conda based releases, it had been decided to use a package versioning system completely independent from the component versioning system. Package versions will be stored as git tags following the pattern {package name}-{version}. All components of a package must have the same tag to be able to make a package. For instance, to make a release 6.4.5 of Morphologist, the tag morphologist-6.4.5 will have to exist on each git repository of Morphologist's components: morphologist-nonfree, morphologist-gpl, morphologist-ui, sulci-nonfree and morpho-deepsulci.
2. Binary compatibility has to be taken into account. Whenever a partially compiled package (such as soma that contains C++ I/O library) has binary dependency on other packages (such as Morphologist that has C++ code using soma I/O), any change to the first one requires to create a new package of the second one even if the version and the code has not changed. To allow this any new release of a package will require a version change of all binary dependent packages. To be able to build tool to help developers to make a release and manage versions to change, all packages will be tagged as either interpreted or compiled. Then, in a branch of the packages dependency tree, all compiled packages will be considered as binary dependent.
3. Packages may differ according to internal dependencies that should not change the results given by a software. For instance we may have several packages of Anatomist for various version of Python or Qt. We will either rely on Conda packages mechanisms for that (especially for Python) or we will make it mandatory to have different version of a package when a dependency is different.

We will have to make two BrainVISA specific tools in soma-forge:

• One command to make a new release of a package that will also make new releases of binary dependent packages.
• One command to make new neuro-forge packages given a Conda channel and a fully build BrainVISA development directory. This will create all packages whose release version in the development tree is not already in the channel.