Here's the current semi-formal way we make a release:
Disclaimer 1: this process aims to be executed simultaneously by different people involved in the FusionForge community. We do not make a release alone in the dark. It's a common and shared process.
Disclaimer 2: sometime all steps are not mandatory.
- Announce intention to make a release on mailto:email@example.com.
- Update src/CHANGES with user-friendly description of what happened since the last release, e.g. . Usually one would make a call to contributors so they update it, if not already.
- Update src/www/index_std.php as well.
- Involve distro packagers (e.g. using Release Candidates) so they have a chance to give feedback if changes are necessary. For Debian, this is us :) - cf. project debian packaging. No other distro right now :/
- Make sure the current release point passes the Test Suite.
- Decide the release at the next weekly meeting.
- Update src/translations/fusionforge.pot (see Translations).
- Tag the precise release point on the release branch.
- Create the archive (everything in ~/src/ directory) [TODO: clean-up methods? e.g. using git-archive?]
- Add the archive at https://fusionforge.org/frs/?group_id=6.
- Make an official announcement on the fusionforge.org front page.
- If possible update fusionforge.org to the new version (showing we drink our own champagne).
- Notify TranslationProject coordinator of the new tarball (see Translations).
- Update all field values in the tracker (add new "Found in version" and "Target release" fields...).
- Push a new Debian version to unstable (and optionally to stable-backports).