Scilab branch policies

Scilab is using a classical way of release. We use a 3 digit numeration system:
Incrementing X is considered as a major release
Y as a medium
Z as a minor

Major releases

We have some major families:

Major/medium releases are done when important modifications are done in the code and they could influence toolboxes, existing codes... Any major evolution of the Scilab language are done through a major release, especially if it introduces compatibility issues.

Medium releases

In a major family, many medium versions are released. Medium releases introduce some important changes, new module, new feature, etc. Some changes in the function profile can also occurs but Scilab language must remains compatible with previous release.

Minor releases

Versions fixing bugs which don't involve big or tricky changes in the code. For example, 5.0.1, 5.0.2 ...

Purpose of each branch

Since we are using git, it is pretty easy to manage the different versions.

The list of branches can be seen on GitWeb.

Main development branches

Temporary development branches

Some other branches are used to avoid disruption while a specific feature is under development. These branches are not supposed to live forever. Once the development they are hosting is completed, they will be merged into the master branch. More information about the purpose of each such temporary branch:

Any other branch

All other branches are dead (no longer used). These are:

Working with branches

Checkout a specific branch

The case does matter.

git clone -b 5.3 5.3

Fixing a bug

See: How to close a bug in Scilab


See these pages :

public: Scilab branch policies (last edited 2012-02-21 14:02:59 by