User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

Site Tools


mantisbt:release_process

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
mantisbt:release_process [2014/02/08 15:36] – Added prerequisites section dregadmantisbt: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/wsvn/collab-maint/ext-maint/mantis/trunk/debian/TestingNewRelease?op=file&rev=0&sc=0 .+For reference, you may also read the [[http://anonscm.debian.org/viewvc/collab-maint/ext-maint/mantis/trunk/debian/TestingNewRelease?view=log|test plan for new Mantis releases in Debian]].
  
  
-===== Localization =====+==== Localization ====
  
 +  * Post on the [[mantisbt-lang@lists.sourceforge.net|Localization mailing list]] to request translation updates from contributors
   * Run /admin/test_langs.php to detect any syntax errors in the localization files.   * Run /admin/test_langs.php to detect any syntax errors in the localization files.
  
  
-===== File Cleanup =====+==== File Cleanup ====
  
   * Run the Lines Termination test script on all the files to make sure the line terminations are UNIX style. <code>   * Run the Lines Termination test script on all the files to make sure the line terminations are UNIX style. <code>
Line 59: Line 64:
  
  
 +===== Preparing the Release =====
  
 +==== Localization ====
  
-====Preparation =====+  * Contact the [[http://translatewiki.net|TranslateWiki]] team (Siebrand) to request an update of tranlations 
 + 
 +==== Repository Preparation ====
  
   * 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 "Testing" section). 
   * Update CREDITS file.   * Update CREDITS file.
-    * If necessary, update the ''.mailmap'' file 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 [[http://www.kernel.org/pub/software/scm/git/docs/git-shortlog.html#_mapping_authors|git shortlog man page]] for details)+    * If necessary, [[mantisbt:mailmap|update the .mailmap file]], so that commit made by the same person under different names and/or e-mail addresses are properly aggregated
     * Run the script to update the Contributor's list <code>     * Run the script to update the Contributor's list <code>
 $ 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/constant_inc.php.   * Update the version number in core/constant_inc.php.
-  * Update doc/RELEASE to include the release notes. 
   * Commit the changes.   * Commit the changes.
  
  
-===== Repository ===== 
  
-  * Create an annotated tag in Gitthe tag should be formatted as "release-1.x.x" +===== Cutting the Release ===== 
-    * For stable releases: GPG-signed tag <code> + 
-$ git checkout master-1.M.x +  * Create an annotated, GPG-signed tag in Gitthe tag should be formatted as ''release-M.N.P'' (e.g. 2.25.4) \\ \\ 
-$ VERSION=1.M.N+     * For **stable releases** <code> 
 +$ git checkout master-M.N 
 +$ VERSION=M.N.P
 $ git tag -s release-$VERSION -m "Stable release $VERSION" $ git tag -s release-$VERSION -m "Stable release $VERSION"
 </code> Note: If this fails, see below for tag signing troubleshooting </code> Note: If this fails, see below for tag signing troubleshooting
-    * For development releases: unsignedannotated tag <code>+    * For **development releases** (e.g. alphabeta, release candidates) <code>
 $ git checkout master $ git checkout master
-$ VERSION=1.M.N +$ VERSION=M.N.P 
-$ git tag -release-$VERSION -m "Development release $VERSION"+$ git tag -release-$VERSION -m "Development release $VERSION"
 </code> </code>
  
Line 94: Line 102:
 </code> </code>
  
-  * In case we are starting a new stable branch, also create it using the format "master-1.x.x": <code> +  * In case we are starting a new stable branch, also create it using the format "master-M.N": <code> 
-$ git branch master-1.x.x master +$ git branch master-M.master 
-$ git push origin master-1.x.x+$ git push origin master-M.N
 </code> </code>
  
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 <code>+Signing the tag fails if GIT cannot map the user with the gpg key, as in the example below <code>
 $ git tag -s release-$VERSION -m "Stable release $VERSION" $ git tag -s release-$VERSION -m "Stable release $VERSION"
 gpg: skipped "Your Name <name@example.com>": secret key not available gpg: skipped "Your Name <name@example.com>": secret key not available
Line 123: Line 131:
  
  
-===== Packaging =====+===== Packaging the Release =====
  
 Generate release tarballs using the ''buildrelease-repo.py'' script found in the ''mantisbt-tools.git'' repository: Generate release tarballs using the ''buildrelease-repo.py'' script found in the ''mantisbt-tools.git'' repository:
 <code> <code>
-$ /path/to/buildrelease-repo.py --fresh --docbook --ref release-$VERSION /path/to/output /path/to/repo+$ /build/buildrelease-repo.py --fresh --docbook --ref release-$VERSION --clean /path/to/output
 </code> </code>
  
-This will create a .zip and .tgz 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 ''/doc'' directory.+This will create the following files in the ''/path/to/output'' directory specified in the command.
  
-[dregad] the script also creates '.asc' fileswhich are not documented in SourceForge section what to do with them ?+  * 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 ''--docbook'' option will automatically build single-file versions of the manuals into the tarball's ''/doc'' directory.
  
-  * Upload the release to Source Forge via the File Manager web interface 
-  * Release through the SF.net mechanism.   
-    * The release name should be "1.2.x" (e.g. 1.2.9).   
-    * Put the release in the appropriate package based on whether it is a stable or a development release.   
-    * Release candidates and alphas are "development" releases. 
-  * Download the release off SF.net and verify correctness. 
-  * Click the "i" next to the files under the folder and do the following actions: 
-    * 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://mantisbt.org/bugs/manage_proj_edit_page.php?project_id=1#versions|Manage Projects page]] for the //mantisbt// project
 +    - Update the version being released (''1.M.x''):
 +      * Rename it to ''1.M.N''
 +      * Update the //Date Order// field to the actual release date
 +      * Copy-paste the text from the release notes into the //Description// field, update as appropriate
 +      * Tick the //Released// box
 +    - Create a new ''1.M.x'' version
 +      * Set the //Date Order// field to a future date <WRAP important 90%>
 +The [[mantisbt:plugins:sourceintegration]] relies on this date to automatically set the //Fixed in version// field when processing commits referencing issues for resolution (i.e. ''Fixes #xxx''). 
  
-===== 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 (e.gwhen cutting a patch release). 
- +</WRAP> 
-  * Update Versions +      * Make sure the //Released// box is not ticked 
-    - Go to the //Manage Projects page// for the //mantisbt// project +
-    - Update the version being released (//1.M.x//): +
-      * Rename it to //1.M.N/+
-      * Update the "Date Order" field to the actual release date +
-      * Copy-paste the text from the release notes into the "Description" field, update as appropriate +
-      * Tick the "Released" box +
-    - Create a new //1.M.x// version +
-      * Set the "Date Order" field to a future date +
-      * Make sure the "Released" box is not ticked+
  
   * 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// = ''1.M.N''
       * Review listed issues, update them as needed (in particular, check that //Resolution// = fixed)       * Review listed issues, update them as needed (in particular, check that //Resolution// = fixed)
 +      * 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 ''1.M.N'' over to the new ''1.M.x'' version 
-      * 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// = ''1.M.N'' 
       * 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 //1.M.x// from the list and click the //Update Target Version// button+      * Select ''1.M.x'' from the list and click the //Update Target Version// button
       * 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 ''$g_latest_version_stable'' or ''$g_latest_version_dev'' as appropriate, to match the version being released     * Update ''$g_latest_version_stable'' or ''$g_latest_version_dev'' as appropriate, to match the version being released
  
 +==== 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 ''/srv/mantisbt-tools/nightly-builds.sh'' 
 +  * Update the //branches// variable to specify the names of all the repository branches for which a nightly build is required 
 + 
 +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. 
 + 
 +<code>$ sudo /srv/mantisbt-tools/nightly-builds.sh</code> 
 + 
 + 
 +==== Deployment ====
  
 This section describes how to deploy the new release on the official and demo bugtrackers on http://mantisbt.org. This section describes how to deploy the new release on the official and demo bugtrackers on http://mantisbt.org.
Line 198: Line 213:
  
  
-===== Automated process (Update script) =====+=== Automated process (Update script) ===
  
   * Execute the following steps, running as root, to update both trackers: <code>   * Execute the following steps, running as root, to update both trackers: <code>
Line 211: Line 226:
 Please refer to the script's help and comments for further details on command-line options. Please refer to the script's help and comments for further details on command-line options.
  
-===== Manual process =====+=== Manual process ===
  
-Also refer to MantisBT Administration Guide [[http://www.mantisbt.org/docs/master-1.2.x/en/administration_guide/admin.install.upgrade.html|upgrade section]].+Also refer to MantisBT Administration Guide [[http://www.mantisbt.org/docs/master-1.3.x/en-US/Admin_Guide/html-desktop/#admin.install.upgrade|upgrade section]].
  
 **Upgrade Official Bug Tracker Instance** **Upgrade Official Bug Tracker Instance**
Line 220: Line 235:
   * Update the code from git <code>   * Update the code from git <code>
 $ cd /srv/www/bugs/ $ cd /srv/www/bugs/
-$ 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
 </code> </code>
   * Upgrade the database if needed (admin/admin_upgrade.php).   * Upgrade the database if needed (admin/admin_upgrade.php).
Line 230: Line 245:
  
  
-**Upgrade Demo Instance**+===== Publishing the Release =====
  
-  * Make sure you are running as root (sudo bash) + 
-  * Update the code from git <code> +==== Source Forge ==== 
-$ cd /srv/www/demo+ 
-$ git checkout master-1.2.x +  * Upload the release to [[http://sourceforge.net/projects/mantisbt/files/|SourceForge]] <WRAP info> 
-$ 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. 
 +</WRAP> 
 +    * manually via SourceForge's File Manager web interface, or 
 +    * with rsync (//USERNAME// is your SourceForge user ID) <code> 
 +rsync -vP --rsh=ssh /path/to/output/* USERNAME@frs.sourceforge.net:/home/frs/project/mantisbt/mantis-stable/$VERSION
 </code> </code>
-  * Upgrade the database if needed (admin/admin_upgrade.php)+  * Download the release off SF.net and verify correctness
-  * Run admin/admin_check.php and resolve any issues+  * Click the ''(i)'' icon next to the files under the folder and do the following actions: 
-  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 #mantishelp to announce the new release and encourage people to use it+  * Update mailing list based on official bug tracker users since users can now signup to our bugtracker to get such announcements
-  * Forums: Announce the release on the Announcements forum+  * Use sendgrid to send out the announcement email. 
-  * Mailing Lists: Send a message to mantisbt-announce / mantisbt-dev to announce the new release and encourage users to upgrade.  Include a link to the version changelog.+ 
 +===== 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/builds.php|Nightly builds]] to reference the proper version in the zip/tarball file name 
 + 
 +  * Edit ''core/constants_inc.php'' 
 +  * Update //MANTIS_VERSION// by incrementing the version number as appropriate: 
 +    * 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)

Driven by DokuWiki