How to prepare a new (feature) release:

1. Commit/merge all changes into the master branch.

2. Update the ChangeLog. Use:
git log --pretty=format:\
"%h | %an | %aD%n%n%B"\
"------------------------------------------------------------------------" \
`git describe --abbrev=0 --tags`..HEAD > log
   in order to create the list of changes.

3. Condense ChangeLog's changes into NEWS file.

4. Commit these changes using the message "New version (psmgmt-6.x.0)".

5. Tag the new release using:
git tag -a -m "Tagging <new-tag>" <new-tag>
   where <new-tag> is of the form 6.x.0

6. Push the newly tagged commits upstream using:
git push --follow-tags


====================================================

The procedure is slightly different for a bugfix release:

1. Create a bugfix-branch for the series of bugfix releases if this is
   the first bugfix release. If the bugfix release is intended to sit
   on top of the last feature release 6.x.0, the name shall be '6.x'
   to satisfy the buildbot. Otherwise builds must be triggered manually.
   All further actions are within this branch unless explicitly stated.

2. Commit/merge all changes foreseen for the bugfix release to this branch

3. Update the ChangeLog. Use:
git log --pretty=format:\
"%h | %an | %aD%n%n%B"\
"------------------------------------------------------------------------" \
`git describe --abbrev=0 --tags`..HEAD > log
   in order to create the list of changes.

4. Condense ChangeLog's changes into NEWS file.

5. Commit these changes using the message "New version (psmgmt-6.x.y)".
   Here <y> is the successor of the last release, i.e. 1 for the first
   bugfix release, etc.

6. Tag the new release using:
git tag -a -m "Tagging <new-tag>" <new-tag>
   where <new-tag> is of the form 6.x.y

7. Push the newly tagged commits upstream using:
git push --follow-tags origin 6.x

8. Merge the bugfix-branch into master and push master to origin

With the most recent changes the buildbot will build all configured
release version automagically (as with normal releases) and let them
end up in the same repositories on hugo.ccc. Thus, no manual
intervention required.


====================================================


Just for completeness here's the version used in SVN times:

1. Check in all changes.
2. Update the ChangeLog. Use 'svn log -r HEAD:lastHead' in order to
   create the list of changes.
3. Condense ChangeLog's changes into NEWS file.
4. Check these changes in using the message "New version (psmgmt-5.1.z)".
5. Tag the new release using 'make -C dist VERSION=5.1.z RELEASE=y tag'.