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>
$ 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
$ /build/buildrelease-repo.py --fresh --docbook --ref release-$VERSION --clean /path/to/output
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 ?
The Source Control Integration plugin relies on this date to automatically set the Fixed in version field when processing commits referencing issues for resolution (i.e.
For this to work properly, it is important that the version targeted by the master branch always has the most recent date. Adjust it if necessary (e.g. when cutting a patch release).
1.M.Nover to the new
1.M.xfrom the list and click the Update Target Version button
$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
Put the files in the appropriate directory, based on the release type: Stable releases go to the mantis-stable; Alpha, Beta and Release candidates go in mantis-development.
Create a sub-directory for the version, matching it's number e.g. 2.0.0-beta.1, 2.23.0, 2.24.4.
$ rsync -vP --rsh=ssh /path/to/output/* USERNAME@frs.sourceforge.net:/home/frs/project/mantisbt/mantis-stable/$VERSION
(i)icon next to the files under the folder and do the following actions:
The notifications below require accounts that only vboctor has access to…
The MantisBT version constant must be increased 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.