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.