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:
For reference, you may also read the test plan for new Mantis releases in Debian.
$ 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 -s 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
When releasing a new major (X+1.0.0) or minor (X.Y+1.0) release, the nightly builds script must be updated so that the files are generated for the appropriate branches.
To make the change permanent, the file should be committed to the mantisbt/mantisbt-tools repository.
If desired, the script may be executed manually at this point. Note that it normally does not produce any output; check the log file at
/var/log/nightly-builds.log for errors.
$ sudo /srv/mantisbt-tools/nightly-builds.sh
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.3.x $ git pull --rebase $ git checkout bugs $ git rebase master-1.3.x
The MantisBT version constant must be increase to reflect the current state of the development branch.
This ensures that people running Mantis from the GIT repository are not led to believe they are working with an official release, and allows the Nightly builds to reference the proper version in the zip/tarball file name.