This is an old revision of the document!
To execute the steps described in this document, the operator must have the following in terms of access rights and setup
This activity should start about 2 weeks before the planned release date.
For major releases, a regression of all features is very desirable. Testing should cover:
The test process for Mantis in the Debian distro can be found at http://svn.debian.org/wsvn/collab-maint/ext-maint/mantis/trunk/debian/TestingNewRelease?op=file&rev=0&sc=0 .
$ cd /path/to/mantisbt $ php -q /path/to/check_lineterm.php -c
$ php -q /path/to/check_lineterm.php -c <filename>
$ php -q /path/to/check_lineterm.php -a <filename>
.mailmapfile at the repository's root, so that commit made by the same person under different names and/or e-mail addresses are properly aggregated (refer to git shortlog man page for details)
$ git checkout master-1.M.x $ VERSION=1.M.N $ git tag -s release-$VERSION -m "Stable release $VERSION"
Note: If this fails, see below for tag signing troubleshooting
$ git checkout master $ VERSION=1.M.N $ git tag -a release-$VERSION -m "Development release $VERSION"
$ git push origin release-$VERSION
$ git branch master-1.x.x master $ git push origin master-1.x.x
Troubleshooting failure to sign tags
Signing the tag fails if GIT cannot map the user with the gpg key, as in the example below
$ git tag -s release-$VERSION -m "Stable release $VERSION" gpg: skipped "Your Name <email@example.com>": secret key not available gpg: signing failed: secret key not available error: gpg failed to sign the data error: unable to sign the tag
For automatic key mapping,
git config user.name and
git config user.email must exactly match the gpg key's uid.
If they don't, there are 2 options:
$ git tag -u <key-id> release-$VERSION -m "Stable release $VERSION"
$ git config [--global] user.signingkey <key-id>
Generate release tarballs using the
buildrelease-repo.py script found in the
$ /path/to/buildrelease-repo.py --fresh --docbook --ref release-$VERSION /path/to/output /path/to/repo
This will create a .zip and .tar.gz tarball of the release, and create a .digest file for each tarball with md5 and sha1 hashes, all in the
/path/to/output directory specified in the command. The
–docbook option will automatically build single-file versions of the manuals into the tarball's
[dregad] the script also creates '.asc' files, which are not documented in SourceForge section - what to do with them ?
$g_latest_version_devas appropriate, to match the version being released
This section describes how to deploy the new release on the official and demo bugtrackers on http://mantisbt.org.
The task can either be performed by executing a script, or manually (aka the hard way); please refer to the relevant section below.
$ cd /srv/www $ ../mantisbt-tools/update-trackers.sh bugs demo
Note: the script is also able to update a single tracker, or to target a specific commit instead of the current upstream branch's HEAD, as follows:
$ ../mantisbt-tools/update-trackers.sh -c <Tag or Commit sha> bugs
Please refer to the script's help and comments for further details on command-line options.
Also refer to MantisBT Administration Guide upgrade section.
Upgrade Official Bug Tracker Instance
$ cd /srv/www/bugs/ $ git checkout master-1.2.x $ git pull --rebase $ git checkout bugs $ git rebase master-1.2.x
Upgrade Demo Instance
$ cd /srv/www/demo/ $ git checkout master-1.2.x $ git pull --rebase $ git checkout demo $ git rebase master-1.2.x
 [dregad] The Build release script does not generate a README file - maybe this is obsolete