linbox
Updating/Versionning

Creating a new version number for LinBox/Givaro/fflas-ffpack:

These software are versioned as projectname-x.y.z where x is a major revision number, y a minor number and z a revision (or bug) number. The script incremente-version — in the root directory of these project sources — takes care of incrementing these numbers (along with the library so-names if necessary).

  • Revision number.
    Minor changes are changes that do not change any API and do not provoke any miscompilation in LinBox. As a consequence, for instance, any release 1.3.z of LinBox should compile with any givaro 3.7.z and any fflas-ffpack 1.6.z.
    This correspondance should be published on the website. It is however always put in the auto-install.sh script.

  • Minor number.
    Any change in these numbers in givaro or fflas-ffpack produces a minor version change in LinBox. A minor version number changed is required when there is some API change in fflas-ffpack or givaro or linbox or anything leading to a failure to compile properly due to newly added inconsistencies.

  • Major number.
    These number are incremented when big change happens. Only the minor number of LinBox is needed to change when a major increment happens in givaro/fflas-ffpack.

Publishing

Before publishing a new version :

  • Testing
    • The buildbots should be green and the script auto-install.sh should succeed and the tests/example pass/compile. (It would be cool if more compilers were tested, namely clang and ekopath).
    • The number of warnings when compiled with –enable-warnings=full should also be minimised.
    • The number of warnings when compiling the doc should be minimised (and new functionalities/concepts documented).

Incrementing

  • on an up-to-date svn source, run the script incremente-version, follow its instruction and confirm.
  • commit these changes as in:
    svn commit -m "updated to projectname-x.y.z"
    so that it is easier to spot the changes in the ChangeLog when publishing it.

Branching
Once the incrementing has been done, if the minor or major number has been changed, then a new branch should be created in the svn repository using

svn copy /path/to/trunk /path/to/branch/project-x.y

This is done in order to allow maintainance and support, eg. new patches from distributions and easy support of a x.y major.minor version (for sage for instance).

Publishing
A release comes with a tar ball tar.gz, a md5sum of it and a summary ChangeLog.

  • LinBox and fflas-ffpack

    • a tar.gz and a md5sum is created in the www directory
    • the corresponding web pages are updated
    • The changes form the ChangeLog should be put in NEWS-a.b.html (even for revision versions) for LinBox and fflas-ffpack-Changelog-x.y.z for fflas-ffpack.

  • Givaro

    • a tar.gz and a md5sum is created and uploaded to the forge where one can also put the ChangeLog in a form.

  • auto-install.sh script
    • the auto-installation script (first 4 lines) should be updated accordingly. They should correspond to the latest stable/desired version number for givaro/fflas-ffpack.
  • ChangeLogs
    It would be nice if the ChangeLogs looked something like (the users cannot/won't view the svn log):

    Date
    - code update :
            * item
    
    - bugs :
            * item
    
    - new features :
            * item

Documentation
If a minor revision change happens, there should be an automatic way to update the doxygen documentation.