Differences

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

--- mantisbt:release_process [2016/10/30 23:52] – Tweaks to version numbers vboctor
+++ mantisbt:release_process [2024/08/25 05:01] (current) – [Notifications] add Mastodon dregad
@@ Line 74: / Line 74: @@
   * Remove references to any debug statements
   * 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>
 $ update-credits.sh
@@ Line 86: / Line 86: @@
 ===== Cutting the Release =====
-  * Create an annotated, GPG-signed tag in Git; the tag should be formatted as "release-1.x.x" \\ \\
+  * Create an annotated, GPG-signed tag in Git; the tag should be formatted as ''release-M.N.P'' (e.g. 2.25.4) \\ \\
      * For **stable releases** <code>
-$ git checkout master-1.M.x
+$ git checkout master-M.N
-$ VERSION=1.M.N
+$ VERSION=M.N.P
 $ git tag -s release-$VERSION -m "Stable release $VERSION"
 </code> Note: If this fails, see below for tag signing troubleshooting
     * For **development releases** (e.g. alpha, beta, release candidates) <code>
 $ git checkout master
-$ VERSION=1.M.N
+$ VERSION=M.N.P
 $ git tag -s release-$VERSION -m "Development release $VERSION"
 </code>
@@ Line 102: / Line 102: @@
 </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.N master
-$ git push origin master-1.x.x
+$ git push origin master-M.N
 </code>
@@ Line 135: / Line 135: @@
 Generate release tarballs using the ''buildrelease-repo.py'' script found in the ''mantisbt-tools.git'' repository:
 <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>
-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 ''/doc'' directory.
+This will create the following files in the ''/path/to/output'' directory specified in the command.
-[dregad] the script also creates '.asc' files, which 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)
+The ''--docbook'' option will automatically build single-file versions of the manuals into the tarball's ''/doc'' directory.
@@ Line 150: / Line 154: @@
   * Update Versions
-    - Go to the //Manage Projects page// for the //mantisbt// project
+    - 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//):
+    - Update the version being released (''1.M.x''):
-      * Rename it to //1.M.N//
+      * Rename it to ''1.M.N''
-      * Update the "Date Order" field to the actual release date
+      * 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
+      * Copy-paste the text from the release notes into the //Description// field, update as appropriate
-      * Tick the "Released" box
+      * Tick the //Released// box
-    - Create a new //1.M.x// version
+    - Create a new ''1.M.x'' version
-      * Set the "Date Order" field to a future date
+      * Set the //Date Order// field to a future date <WRAP important 90%>
-      * Make sure the "Released" box is not ticked
+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'').
+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).
+</WRAP>
+      * Make sure the //Released// box is not ticked
   * Update issues
     - Go to the //View Issues page//
     - 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)
+      * Private security issues should be made public
       * Tick the //Select all// checkbox
       * Select //Close// and click OK
       * Click the //Close Issues// button
       * 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
       * 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
@@ Line 182: / Line 191: @@
     * Edit main website's config file ''/srv/www/main/config_inc.php''
     * Update ''$g_latest_version_stable'' or ''$g_latest_version_dev'' as appropriate, to match the version being released
+==== Nightly builds ====
+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>
@@ Line 228: / Line 250: @@
 ==== Source Forge ====
-  * Upload the release to [[http://sourceforge.net/projects/mantisbt/files/|SourceForge]] via the File Manager web interface
+  * Upload the release to [[http://sourceforge.net/projects/mantisbt/files/|SourceForge]] <WRAP info>
-  * Release through the SF.net mechanism.
+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**.
-    * The release name should be "1.3.x" (e.g. 1.3.3).
-    * Put the release in the appropriate package based on whether it is a stable or a development release.
+Create a sub-directory for the version, matching it's number e.g. 2.0.0-beta.1, 2.23.0, 2.24.4.
-    * Release candidates, alphas and betas are "development" releases.
+</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>
   * Download the release off SF.net and verify correctness.
-  * Click the "i" next to the files under the folder and do the following actions:
+  * Click the ''(i)'' icon next to the files under the folder and do the following actions:
     * for digests, exclude them from stats.
     * In case of a stable release, make the zip file the default for all platforms.
@@ Line 241: / Line 267: @@
   * Blog: Post an announcement
+  * [[https://matrix.to/#/#mantisbt_mantisbt:gitter.im|Gitter]]: Post an announcement
+  * [[https://phpc.social/@mantisbt|Mastodon]]: Post an announcement
+The notifications below require accounts that only vboctor has access to...
   * Twitter: announce the release via mantisbt twitter account.
   * Update mailing list based on official bug tracker users since users can now signup to our bugtracker to get such announcements.
   * Use sendgrid to send out the announcement email.
+===== 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