Committee on Stable Releases and Versioning

Comittee Members:

  • Laci Ladanyi
  • Francois Margot
  • JP Fasano

Each module has a stable version and a development version. The stable version is supposed to be left unchanged, except minor bug fixes, at the discretion of the project leader. (More than one stable version can be available, but in the following "stable version" refers to the most recent one). The development version is more or less working as what we have now. Every stable version must include a working compilable and executable unitTest code. Naming conventions are as follows:

Versioning scheme: major.minor.tiny

(adopted from Linux kernel versioning)

major number changes:

anything can change (though drastic changes that screw up everything are not recommended)

minor number changes:

nothing should break that was working, i.e., existing interfaces must not change, but new interfaces can be added.
NOTE: even minor numbers indicate stable versions, odd minors indicate development versions. In devel versions (almost) anything goes.

tiny number changes:

only bugfixes (or if another project has a newer stable release, and this project works with it, then the maintainer can release a new stable version for this project by bumping up the tiny number).

Project Leaders:

Project leaders have the freedom to schedule a stable release of their module. They must announce the release of a new stable version on the coin mailing lists. When a new stable release is created, it must be working with the most recent stable version of all other modules it depends on.

Ideally, downloading the stable versions of all modules in COIN gives a set of working modules. However, for some modules that are used by several other modules (like Coin, Osi, possibly Clp) new stable releases might require update of dependent modules. There might be some time while a dependent module is not working with the most recent stable version of the module. Reminding the project leader of the need to update his module can possibly be done automatically by email.


A mechanism for dowloading the correct stable versions corresponding to a given stable version of a module should be available. This is apparently easy to do in svm. By default, the user should get stable versions of all modules. He should get the devel version only if he request it specifically.

Problems might arise if a user works with one module (like Ipotp) requiring stable releases of say, the stable Coin module of December 2005, and with another one (Bcp) that requires the stable Coin module of June 2005. We should check what svm would do in this situation (dowload two stable releases of Coin?).


It seems that waiting for the migration to svm before implementing stable releases is reasonable.

Last modified 13 years ago Last modified on Jan 21, 2006 9:42:04 AM