More release meta fixes (#965)

.github/workflows/publish-beta.yml

@@ -1,4 +1,4 @@
-name: "Publish"
+name: "Publish to beta listings"
 on:
   push:
     tags:
@@ -8,6 +8,8 @@ jobs:
   build-release:
     runs-on: ubuntu-latest
     steps:
+    # TODO: somehow check if the pushed tag was a backport (i.e. it's a lower
+    # version than the latest beta release) and don't publish those. #964
     - uses: actions/checkout@v3
     - uses: actions/setup-node@v3
     - run: npm ci

.github/workflows/publish-stable.yml

@@ -1,4 +1,4 @@
-name: "Publish"
+name: "Publish to stable listings"
 on:
   push:
     tags:

CONTRIBUTING.md

@@ -102,13 +102,14 @@ As an example, a release timeline might look something like this:
 ### Tagging a New Release
 
 1. Make sure the working directory is clear and you're on the `master` branch.
-2. Run `npm run release`. This script will prompt you for the new four-segment version number, then the release name.
+2. Update `firefox_manifest.json`'s `strict_min_version` to the latest ESR version of Firefox. [Here's a link to the FF release calendar for reference](https://whattrainisitnow.com/calendar/). (TODO: automate this somehow. this is necessary because AMO will eventually prevent you from uploading extensions where this number is too low, but we want to set it to _something_ to prevent people from using the extension in browser versions where it will obviously not work.)
+3. Run `npm run release`. This script will prompt you for the new four-segment version number, then the release name.
    - Ensure the major.minor.patch is set correctly. You should only need to update this if the previous release was a stable release.
    - If the previous release was a beta release, increment the build number by 1. If the previous release was a stable release, instead reset the build number _to_ 1.
    - We generally only change the release name for major or minor bumps. If you're making a stable release and didn't change this during the beta series, make sure you update this to something appropriate for the new release. Tradition dictates it should be an adjective related to the development of the release, and an animal which start with the same letter.
 
    The script will then automatically commit and tag the release in your local clone.
-3. Verify that the commit created by the release script contains nothing except changes to the version strings in the manifest files.
-4. Push the commit and tag: `git push && git push --tags`.
+4. Verify that the commit created by the release script contains nothing except changes to the version strings in the manifest files.
+5. Push the commit and tag: `git push && git push --tags`.
 
 Once your tag is pushed to Github, the CI pipeline will generate release builds and automatically submit them to extension stores. Beta releases will be sent only to the beta listings; stable releases will result in updates to both the stable _and_ beta listings, with the beta listing receiving a beta-flagged build containing otherwise the same code.

extension/firefox_manifest.json

@@ -9,7 +9,7 @@
     "browser_specific_settings": {
         "gecko": {
             "id": "yes@jetpack",
-            "strict_min_version": "57.0"
+            "strict_min_version": "115.13"
         }
     },
     "permissions": [