Consistently use "bugfix release" terminology.

… and not "point-release" nor "minor release".

wiki/src/blueprint/monthly_report.mdwn

@@ -98,7 +98,7 @@ Template
     Releases
     ========
 
-    * \[[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|minor|emergency] release).
+    * \[[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|bugfix|emergency] release).
 
     * Tails VERSION+1 is \[[scheduled for MONTH DAY|contribute/calendar]].
 

wiki/src/blueprint/monthly_report/report_2018_10.mdwn

@@ -7,7 +7,7 @@
 Releases
 ========
 
-* [[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|minor] release).
+* [[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|bugfix] release).
 
 * Tails VERSION+1 is [[scheduled for MONTH DAY|contribute/calendar]].
 

wiki/src/blueprint/monthly_report/report_2018_11.mdwn

@@ -7,7 +7,7 @@
 Releases
 ========
 
-* [[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|minor] release).
+* [[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|bugfix] release).
 
 * Tails VERSION+1 is [[scheduled for MONTH DAY|contribute/calendar]].
 

wiki/src/blueprint/monthly_report/report_2018_12.mdwn

@@ -7,7 +7,7 @@
 Releases
 ========
 
-* [[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|minor] release).
+* [[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|bugfix] release).
 
 * Tails VERSION+1 is [[scheduled for MONTH DAY|contribute/calendar]].
 

wiki/src/contribute/APT_repository.mdwn

@@ -57,7 +57,7 @@ release (`testing`):
    Tails ISO build).
 
 When building an ISO from the branch used to prepare the next
-point-release (`stable`) we use the same time-based snapshots that
+bugfix release (`stable`) we use the same time-based snapshots that
 were used to prepare the latest Tails release, except:
 
  * we use our latest snapshot of security.debian.org;

wiki/src/contribute/APT_repository/custom.mdwn

@@ -363,16 +363,16 @@ In any case:
            -m "Add dummy changelog entry for ${NEXT_PLANNED_MAJOR_VERSION:?}."
 
 * increment the version number in stable's `debian/changelog` to match
-  the next point release, so that
+  the next bugfix release, so that
   next builds from the `stable` branch do not use the APT suite meant
   for the last release:
 
         cd "${RELEASE_CHECKOUT}" && \
         git checkout stable && \
-        dch --newversion "${NEXT_PLANNED_MINOR_VERSION:?}" \
+        dch --newversion "${NEXT_PLANNED_BUGFIX_VERSION:?}" \
            "Dummy entry for next release." && \
         git commit debian/changelog \
-           -m "Add dummy changelog entry for ${NEXT_PLANNED_MINOR_VERSION:?}."
+           -m "Add dummy changelog entry for ${NEXT_PLANNED_BUGFIX_VERSION:?}."
 
 ### Else, if you just released a RC
 

wiki/src/contribute/design.mdwn

@@ -1346,7 +1346,7 @@ Remaining applications, including the base system, will be upgraded
 using Debian standard upgrade process, and generally based on the
 latest Debian stable release so there are not many problems.
 
-We intend to build and publish point releases (e.g.
+We intend to build and publish bugfix releases (e.g.
 [[0.6.1|news/version_0.6.1]]) in a timely manner when security issues
 affect Tails. Such releases are based on the [[stable Git
 branch|contribute/git]] and can thus also fix important — although not

wiki/src/contribute/design/incremental_upgrades.mdwn

@@ -53,7 +53,7 @@ Test-BDD-Cucumber]], in the `features/frontend` directory of the `iuk`
 
 ## As a Tails developer
 
-### When I prepare a point-release
+### When I prepare a bugfix release
 
 #### I should prepare an IUK
 

wiki/src/contribute/how/code/HACKING.mdwn

@@ -27,7 +27,7 @@ you have something to contribute, please read our
   up. In general you should base new branches on this one.
 
 * `stable`: When a new major Tails release is out, we merge `devel`
-  into `stable` and use it to build minor releases (e.g. when there's
+  into `stable` and use it to build bugfix releases (e.g. when there's
   a new Tor Browser (= Firefox ESR) release) and emergency releases
   from. We only merge security fixes and bugfixes into this branch, so
   new such branches should be based on `stable`.

wiki/src/contribute/how/documentation/release_notes.mdwn

@@ -15,10 +15,10 @@
     - If a release candidate was announced, read the call for testing
     - Analyze the changes already made on the website and link to them:
       - in testing for a major release: `git diff origin/master...origin/testing wiki/src/**/*.{mdwn,html}`
-      - in stable for a minor release: `git diff origin/master...origin/stable wiki/src/**/*.{mdwn,html}`
+      - in stable for a bugfix release: `git diff origin/master...origin/stable wiki/src/**/*.{mdwn,html}`
     - Analyze the diff of packages
       - in testing for a major release: `wget http://nightly.tails.boum.org/build_Tails_ISO_testing/lastSuccessful/archive/latest.iso.packages`
-      - in stable for a minor release: `wget http://nightly.tails.boum.org/build_Tails_ISO_stable/lastSuccessful/archive/latest.iso.packages`
+      - in stable for a bugfix release: `wget http://nightly.tails.boum.org/build_Tails_ISO_stable/lastSuccessful/archive/latest.iso.packages`
       - `diff -u ~/Persistent/master/wiki/src/torrents/files/tails-amd64-*.packages latest.iso.packages | wdiff --diff-input --terminal --auto-pager`
     - If an important application was updated to a new upstream release, read its Changelog to find relevant highlights:
       - Tor: <https://blog.torproject.org/>

wiki/src/contribute/release_process.mdwn

@@ -48,8 +48,8 @@ the scripts snippets found on this page:
   the 3.9 major release, then set this to 3.12 (3.9 is the next major
   release, 3.10 and 3.11 are bugfix releases, 3.12 is a major
   release).
-* `NEXT_PLANNED_MINOR_VERSION`: set to the version number of the next
-  *minor* Tails release; if the next release is a point-release, use
+* `NEXT_PLANNED_BUGFIX_VERSION`: set to the version number of the next
+  *bugfix* Tails release; if the next release is a bugfix release, use
   that one; otherwise, use `${VERSION}.1`
 * `MAJOR_RELEASE`: set to 1 if preparing a major release or a release
   candidate for a major release, to 0 otherwise
@@ -124,10 +124,10 @@ If we are at freeze time for a major release:
    [[APT_repository/time-based_snapshots#bump-expiration-date-for-all-snapshots]]
 
 
-Point-release
--------------
+Bugfix release
+--------------
 
-If we are at freeze time for a point-release:
+If we are at freeze time for a bugfix release:
 
 1. Merge the `master` Git branch into `stable`:
 
@@ -137,8 +137,8 @@ If we are at freeze time for a point-release:
    listed in the `stable` branch's `config/APT_overlays.d/` into the `stable`
    APT suite.
 
-Common steps for point and major releases
------------------------------------------
+Common steps for bugfix and major releases
+------------------------------------------
 
 Reset the release branch's `config/base_branch`:
 
@@ -163,7 +163,7 @@ Update included files
 Upgrade bundled binary Debian packages
 --------------------------------------
 
-Skip this section if you are preparing a point-release.
+Skip this section if you are preparing a bugfix release.
 
 The goal here is to make sure the bundled binary Debian packages contain
 up-to-date localization files, so:
@@ -257,11 +257,11 @@ Major release
 listed in the `testing` branch's `config/APT_overlays.d/` into the `testing`
 custom APT suite.
 
-Point-release
--------------
+Bugfix release
+--------------
 
 <div class="note">
-For point-releases, we generally do not put any RC out, so freeze time
+For bugfix releases, we generally do not put any RC out, so freeze time
 is the same as preparing the actual release. Hence, the following
 steps have already been done above, and this section is a noop in the
 general case.
@@ -761,7 +761,7 @@ Prepare upgrade-description files
             --version "${VERSION:?}" \
             --next-version "${NEXT_PLANNED_MAJOR_VERSION:?}" \
             --next-version "${NEXT_PLANNED_MAJOR_VERSION:?}~rc1" \
-            --next-version "${NEXT_PLANNED_MINOR_VERSION:?}" \
+            --next-version "${NEXT_PLANNED_BUGFIX_VERSION:?}" \
             --next-version "${VERSION:?}.1" \
             --iso "${ISO_PATH:?}" \
             --previous-version "${PREVIOUS_VERSION:?}" \

wiki/src/contribute/release_schedule.mdwn

@@ -47,7 +47,7 @@ Postponing the final release causes problems for those who have
 scheduled time for post-release user support, press work, etc..
 
 Also, changing our mind (i.e. releasing a point-release instead of
-a major one) => switching minor/major release schedule for the future
+a major one) => switching bugfix/major release schedule for the future
 is probably not an option either.
 
 So we need to have a pessimistic enough RC->final schedule to handle