Layout:

 - 'master'  branch is used to prepare for the next feature release. The
   formal definition for a feature release is given later.

 - 'maint' branch is used to prepare the next maintenance release. After
   the  release of an feature release this branch is set to this version
   and bug fixes will accumulated in this branch. After some  time  this
   version  is tagged as a maintenance release. The formal definition of
   a feature release is given later. Setting this branch to the  release
   is  done by _merging_ the release into maint. master will merge maint
   from time to time. In a perfect feature  release  'maint'  is  merged
   into master, master merged to maint and the feature release is tagged
   from the master branch.

   Further feature modifications are done in master and  maintenance  is
   done in maint.


Feature release:

 - A  feature  release  is  named vX.Y.Z. It should include bugfixes and
   enhancements. It should be free of known bugs and regressions. A  new
   feature  release will stop the current maintenance of the old feature
   release. All changes in the maint branch must be  included  into  the
   master branch.


Maintenance release:

 - A  maintenance  release  is named vX.Y.Z.W and includes only bugfixes
   for the vX.Y.Z feature release and previous maintenance  releases  of
   the vX.Y.Z feature release.


Preparing a release:

 - Check if you are using git 1.6.x or better - otherwise the experimental
   directory will not be stripped from release tarball

 - Check again that you are on the right branch. 'maint' for a maintenance
   release vX.Y.Z.W and master for a feature release vX.Y.Z

 - Check the mailing list if there are any patches for the maint branch

 - Merge branch maint if needed

 - Update the version number at the beginning of /CMakeLists.txt

 - Test if the whole repository builds with all dependencies fulfilled.

   - Try build with configure options -DBUILD_LTO=ON and-DBUILD_LTO=OFF

   - Try to compile it with stricter linker flags to test correct linking
     behavior of all libraries and executables

       $ mkdir build
       $ cd build
       $ LDFLAGS="-Wl,--no-add-needed -Wl,--no-undefined" cmake ..
       $ make

     --no-add-needed can be omitted with GNU gold as it doesn't support the
     option but uses the behavior as default.

 - Search for existing bugs which are blockers for the upcoming release

 - Update the release notes in Documentation/RelNotes-X.Y.Z.txt

 - Tag the current version with `git tag -s vX.Y.Z -m 's3d X.Y.Z'`

 - Push heads and tags with

     $ git push
     $ git push --tags

 - Create compressed source tarballs with

     $ VERSION=X.Y.Z
     $ git archive --format=tar --prefix="s3d-$VERSION/" "v$VERSION"  >  "s3d-$VERSION.tar"
     $ gzip -n -m -c "s3d-$VERSION.tar" > "s3d-$VERSION.tar.gz"
     $ xz "s3d-$VERSION.tar"

 - Create the api tarballs with

     $ VERSION=X.Y.Z
     $ rm -rf api_build
     $ mkdir api_build
     $ cd api_build
     $ cmake ..
     $ cd Documentation
     $ make
     $ mv doc_output s3dapi_doc-"$VERSION"
     $ find s3dapi_doc-"$VERSION" -type f |sed 's/^\.*\/*//'|sort > manifest
     $ tar cf s3dapi_doc-"$VERSION".tar --owner 0 --group 0 --numeric-owner --mode 0644 --files-from manifest
     $ gzip -n -m -c "s3dapi_doc-$VERSION.tar" > "s3dapi_doc-$VERSION.tar.gz"
     $ xz "s3dapi_doc-$VERSION.tar"

 - Add files to SourceForge using https://sourceforge.net/projects/s3d/files/

 - Add RelNotes-* as README to the same folder

 - Get current webpage from web.sourceforge.net

     $ rsync -aPc USERNAME@web.sourceforge.net:/home/project-web/s3d/htdocs/ s3d_htdocs
     $ s3d_htdocs

 - Change index.xhtml to announce the new release

 - Extract api tarball to doc/X.Y.Z

 - Add it to repository with `git add doc/X.Y.Z` and insert it to doc/index.xhtml

 - Commit the changes

 - Sync the webpage

     $ rsync -aPc . USERNAME@web.sourceforge.net:/home/project-web/s3d/htdocs/

 - Add a release note to http://freshmeat.net/projects/s3d_
