Release numbering

1.x

Feature release.

1.0.x

Bugfix release.

Feature Releases

• Update the CMake build environment.
  • Test it (using CMake v2.6)
    • both Visual Studio 2005 and 2007
      • both from the IDE and using nmake
      • test creating an installer.
    • with linux (using gcc-4.x)
• Check the repository thoroughly
  • Be sure there is no a globally installed version of lemon on the computer where the tests are made
  • Run make distcheck
  • Do make check
    • using gcc version 3.3, 3.4, 4.0, 4.1, 4.2, 4.3. No warning is allowed with these version
    • using icc 10.1
    • Both on 32 bit and 64 bit architectures.
    • on Cygwin
    • on OSX
• Tag the tip with 1.0-base.
  • Alternatively, should we call it 1.0-parent? (c.f. Mercurial Queue)
• Create a named branch for each new feature release. The name is just the release number like 1.0.
• Then comes some commits (out of the default branch) preparing the repository for the release.
  • Remove all unfinished stuff (e.g. from the documentation)
  • Set the release number in configure.ac
• Run make update-external-tags to get doxygen reference to STL.
• Run make distcheck
  • This will create the tarball.
• Create the Windows installer.
• Tag the released version with lemon-x.y.

Bugfix Changesets

• Do the bugfix on the top of the common ancestor changeset of all branches where the bug appears (e.g. on the top of 1.0-base).
• Then merge them individually to all branches where it applies.

Bugfix Releases

• A bugfix release is situated in the same branch as its mother feature release.
• Check the repository thoroughly
  • Like in case of a feature release
• Adjust the release number in configure.ac
  • Don't forget to commit this change.
• Create the tarball and the Windows installer.
• Tag the released version with lemon-x.y.z.