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 <firstname.lastname@example.org>": 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