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.