mantisbt:release_process
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
mantisbt:release_process [2014/02/08 15:36] – Added prerequisites section dregad | mantisbt:release_process [2022/05/10 10:07] (current) – [Packaging the Release] asc files are ascii-armored signature files dregad | ||
---|---|---|---|
Line 18: | Line 18: | ||
- | ===== Readiness | + | ===== Planning the Release |
+ | |||
+ | This activity should start about 2 weeks before the planned release date. | ||
+ | |||
+ | ==== General Readiness | ||
* Review the issues in bugtracker to make sure there are no critical issues that need to be included in the release. | * Review the issues in bugtracker to make sure there are no critical issues that need to be included in the release. | ||
* Check with the developers (via the mailing list and/or IRC) that there are no pending issues for the release. | * Check with the developers (via the mailing list and/or IRC) that there are no pending issues for the release. | ||
- | ===== Testing | + | ==== Testing ==== |
* General testing. | * General testing. | ||
Line 37: | Line 41: | ||
* optional features (e.g., graphs) | * optional features (e.g., graphs) | ||
- | The test process for Mantis in the Debian distro can be found at http://svn.debian.org/ | + | For reference, you may also read the [[http://anonscm.debian.org/ |
- | ===== Localization | + | ==== Localization ==== |
+ | * Post on the [[mantisbt-lang@lists.sourceforge.net|Localization mailing list]] to request translation updates from contributors | ||
* Run / | * Run / | ||
- | ===== File Cleanup | + | ==== File Cleanup ==== |
* Run the Lines Termination test script on all the files to make sure the line terminations are UNIX style. < | * Run the Lines Termination test script on all the files to make sure the line terminations are UNIX style. < | ||
Line 59: | Line 64: | ||
+ | ===== Preparing the Release ===== | ||
+ | ==== Localization ==== | ||
- | ===== Preparation | + | * Contact the [[http:// |
+ | |||
+ | ==== Repository | ||
* Remove references to any debug statements | * Remove references to any debug statements | ||
- | * Make sure enough testing is done for the main functionality and the admin section (see the " | ||
* Update CREDITS file. | * Update CREDITS file. | ||
- | * If necessary, update the '' | + | * If necessary, |
* Run the script to update the Contributor' | * Run the script to update the Contributor' | ||
$ update-credits.sh | $ update-credits.sh | ||
Line 72: | Line 80: | ||
* If needed, make any additional changes manually | * If needed, make any additional changes manually | ||
* Update the version number in core/ | * Update the version number in core/ | ||
- | * Update doc/RELEASE to include the release notes. | ||
* Commit the changes. | * Commit the changes. | ||
- | ===== Repository ===== | ||
- | | + | ===== Cutting the Release ===== |
- | * For stable releases: GPG-signed tag < | + | |
- | $ git checkout master-1.M.x | + | |
- | $ VERSION=1.M.N | + | |
+ | $ git checkout master-M.N | ||
+ | $ VERSION=M.N.P | ||
$ git tag -s release-$VERSION -m " | $ git tag -s release-$VERSION -m " | ||
</ | </ | ||
- | * For development releases: unsigned, annotated tag < | + | * For **development releases** (e.g. alpha, beta, release candidates) |
$ git checkout master | $ git checkout master | ||
- | $ VERSION=1.M.N | + | $ VERSION=M.N.P |
- | $ git tag -a release-$VERSION -m " | + | $ git tag -s release-$VERSION -m " |
</ | </ | ||
Line 94: | Line 102: | ||
</ | </ | ||
- | * In case we are starting a new stable branch, also create it using the format " | + | * In case we are starting a new stable branch, also create it using the format " |
- | $ git branch master-1.x.x master | + | $ git branch master-M.N master |
- | $ git push origin master-1.x.x | + | $ git push origin master-M.N |
</ | </ | ||
Line 103: | Line 111: | ||
**Troubleshooting failure to sign tags** | **Troubleshooting failure to sign tags** | ||
- | Signing the tag fail if GIT cannot map the user with the gpg key, as in the example below < | + | 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 " | $ git tag -s release-$VERSION -m " | ||
gpg: skipped "Your Name < | gpg: skipped "Your Name < | ||
Line 123: | Line 131: | ||
- | ===== Packaging ===== | + | ===== Packaging |
Generate release tarballs using the '' | Generate release tarballs using the '' | ||
< | < | ||
- | $ /path/to/ | + | $ /build/ |
</ | </ | ||
- | This will create | + | This will create the following files in the ''/ |
- | [dregad] | + | * a //.zip// and //.tar.gz// tarball of the release |
+ | * a //.digest// file for each tarball with //md5// and, //sha*// hashes | ||
+ | * an ASCII-armored GPG signature file for each tarball (with //.asc// extension) | ||
- | ===== Source Forge ===== | + | The '' |
- | * Upload the release to Source Forge via the File Manager web interface | ||
- | * Release through the SF.net mechanism. | ||
- | * The release name should be " | ||
- | * Put the release in the appropriate package based on whether it is a stable or a development release. | ||
- | * Release candidates and alphas are " | ||
- | * Download the release off SF.net and verify correctness. | ||
- | * Click the " | ||
- | * for digests, exclude them from stats. | ||
- | * for zip make it default for all platforms. | ||
- | * for README file exclude from stats. [1] | ||
- | * Post news on Mantis SF project area. | ||
- | [1] [dregad] The Build release script does not generate a README file - maybe this is obsolete | ||
+ | ===== Updating mantisbt.org ===== | ||
+ | ==== Bugtracker ==== | ||
+ | * Update Versions | ||
+ | - Go to the [[https:// | ||
+ | - Update the version being released ('' | ||
+ | * Rename it to '' | ||
+ | * Update the //Date Order// field to the actual release date | ||
+ | * Copy-paste the text from the release notes into the // | ||
+ | * Tick the // | ||
+ | - Create a new '' | ||
+ | * Set the //Date Order// field to a future date <WRAP important 90%> | ||
+ | The [[mantisbt: | ||
- | ===== Bugtracker ===== | + | 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 |
- | + | </WRAP> | |
- | * Update Versions | + | * Make sure the //Released// box is not ticked |
- | - Go to the //Manage Projects page// for the //mantisbt// project | + | |
- | - Update | + | |
- | * Rename it to //1.M.N// | + | |
- | * Update | + | |
- | * Copy-paste the text from the release notes into the " | + | |
- | * Tick the " | + | |
- | - Create a new //1.M.x// version | + | |
- | * Set the "Date Order" field to a future date | + | |
- | * Make sure the " | + | |
* Update issues | * Update issues | ||
- Go to the //View Issues page// | - Go to the //View Issues page// | ||
- Close all resolved issues that are fixed in the version being released | - Close all resolved issues that are fixed in the version being released | ||
- | * Set a new filter: //Status// = resolved, //Fixed in Version// = 1.M.N | + | * Set a new filter: //Status// = resolved, //Fixed in Version// = '' |
* Review listed issues, update them as needed (in particular, check that // | * Review listed issues, update them as needed (in particular, check that // | ||
+ | * Private security issues should be made public | ||
* Tick the //Select all// checkbox | * Tick the //Select all// checkbox | ||
* Select //Close// and click OK | * Select //Close// and click OK | ||
* Click the //Close Issues// button | * Click the //Close Issues// button | ||
* Repeat until the filter is empty | * Repeat until the filter is empty | ||
- | - Carry open issues still targeted to 1.M.N over to the new 1.M.x version | + | - Carry open issues still targeted to '' |
- | * Set a new filter: //Hide Status// = closed (And Above), //Target Version// = 1.M.N | + | * Set a new filter: //Hide Status// = closed (And Above), //Target Version// = '' |
* Tick the //Select all// checkbox | * Tick the //Select all// checkbox | ||
* Select //Update Target Version// and click OK | * Select //Update Target Version// and click OK | ||
- | * Select | + | * Select |
* Repeat until the filter is empty | * Repeat until the filter is empty | ||
- | ===== Website | + | ==== Website ==== |
* Update the //latest version// | * Update the //latest version// | ||
Line 190: | Line 192: | ||
* Update '' | * Update '' | ||
+ | ==== Nightly builds ==== | ||
- | ===== Deployment | + | 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. |
+ | |||
+ | * Edit the script ''/ | ||
+ | * Update the // | ||
+ | |||
+ | To make the change permanent, the file should be committed to the // | ||
+ | |||
+ | 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 ''/ | ||
+ | |||
+ | < | ||
+ | |||
+ | |||
+ | ==== Deployment ==== | ||
This section describes how to deploy the new release on the official and demo bugtrackers on http:// | This section describes how to deploy the new release on the official and demo bugtrackers on http:// | ||
Line 198: | Line 213: | ||
- | ===== Automated process (Update script) | + | === Automated process (Update script) === |
* Execute the following steps, running as root, to update both trackers: < | * Execute the following steps, running as root, to update both trackers: < | ||
Line 211: | Line 226: | ||
Please refer to the script' | Please refer to the script' | ||
- | ===== Manual process | + | === Manual process === |
- | Also refer to MantisBT Administration Guide [[http:// | + | Also refer to MantisBT Administration Guide [[http:// |
**Upgrade Official Bug Tracker Instance** | **Upgrade Official Bug Tracker Instance** | ||
Line 220: | Line 235: | ||
* Update the code from git < | * Update the code from git < | ||
$ cd / | $ cd / | ||
- | $ git checkout master-1.2.x | + | $ git checkout master-1.3.x |
$ git pull --rebase | $ git pull --rebase | ||
$ git checkout bugs | $ git checkout bugs | ||
- | $ git rebase master-1.2.x | + | $ git rebase master-1.3.x |
</ | </ | ||
* Upgrade the database if needed (admin/ | * Upgrade the database if needed (admin/ | ||
Line 230: | Line 245: | ||
- | **Upgrade Demo Instance** | + | ===== Publishing the Release ===== |
- | * Make sure you are running as root (sudo bash) | + | |
- | * Update | + | ==== Source Forge ==== |
- | $ cd /srv/www/demo/ | + | |
- | $ git checkout master-1.2.x | + | * Upload |
- | $ git pull --rebase | + | 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**. |
- | $ git checkout demo | + | |
- | $ git rebase master-1.2.x | + | Create a sub-directory for the version, matching it's number e.g. 2.0.0-beta.1, 2.23.0, 2.24.4. |
+ | </ | ||
+ | * manually via SourceForge' | ||
+ | * with rsync (// | ||
+ | $ rsync -vP --rsh=ssh / | ||
</ | </ | ||
- | * Upgrade | + | * Download |
- | * Run admin/ | + | * Click the '' |
- | * Login and do simple testing. | + | * for digests, exclude them from stats. |
+ | * In case of a stable release, make the zip file the default for all platforms. | ||
- | ===== Notification ===== | + | ==== Notifications |
* Blog: Post an announcement | * Blog: Post an announcement | ||
+ | * Gitter: Post an announcement | ||
+ | |||
+ | The notifications below require accounts that only vboctor has access to... | ||
+ | |||
* Twitter: announce the release via mantisbt twitter account. | * Twitter: announce the release via mantisbt twitter account. | ||
- | * IRC: Change the title of # | + | * Update mailing list based on official bug tracker users since users can now signup |
- | * Forums: Announce | + | * Use sendgrid to send out the announcement email. |
- | * Mailing Lists: Send a message | + | |
+ | ===== Prepare for next release | ||
+ | |||
+ | ==== Bump the version number ==== | ||
+ | |||
+ | 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 [[https://mantisbt.org/ | ||
+ | |||
+ | * Edit '' | ||
+ | * Update // | ||
+ | * Major version: **x+1**.0.0**-dev** | ||
+ | * Minor version: x.**y+1**.0**-dev** | ||
+ | * Patch version: x.y.**z+1-dev** | ||
+ | * Commit and push the modified file | ||
mantisbt/release_process.1391891813.txt.gz · Last modified: 2014/02/08 15:51 (external edit)