Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/toolbox-team/reddit-moderator-toolbox/llms.txt

Use this file to discover all available pages before exploring further.

Toolbox releases are managed through a structured version numbering scheme and a semi-automated release script. Once a tag is pushed to GitHub, the CI pipeline builds and submits the extension to the browser stores automatically — the only manual steps are tagging correctly and verifying that the commit is clean.

​
Version format

Toolbox uses two parallel identifiers for each release:
IdentifierFormatExampleWhere it appears
Manifest versionmajor.minor.patch.build7.0.0.3manifest.json version field
Git tag (stable)vMajor.minor.patchv7.0.0Git tag
Git tag (beta)vMajor.minor.patch-beta.buildv7.0.0-beta.3Git tag
version_namemajor.minor.patch "Release Name"7.0.0 "Delaying Donkey"manifest.json version_name field, store listings
The build number resets to 1 whenever the major.minor.patch changes (i.e. on the first beta of a new feature release or any hotfix). Subsequent releases on the same major.minor.patch increment the build number, including the final stable promotion.

​
Naming convention

Release names follow the pattern adjective + animal, where both words start with the same letter (e.g. Delaying Donkey, Pensive Penguin). The name traditionally reflects something about the development cycle of that release. Names are only changed for major or minor version bumps — patch-level hotfixes reuse the existing name.

​
Release timeline example

The table below illustrates how version numbers evolve across a typical release cycle:
Manifest versionGit tagRelease typeNotes
7.0.0.1v7.0.0-beta.1betaDevelopment of 7.0.0 begins
7.0.0.2v7.0.0-beta.2betaIteration in the beta channel
......beta
7.0.0.21v7.0.0-beta.21betaLast beta release of 7.0.0
7.0.0.21v7.0.0stableSame build promoted to stable
7.0.1.1v7.0.1stableHotfix — no beta needed
7.0.2.1v7.0.2stableAnother hotfix
7.1.0.1v7.1.0-beta.1betaDevelopment of 7.1.0 begins
The final beta build and the stable release share the same manifest version (e.g. 7.0.0.21). The stable promotion is a separate tag on the same commit rather than a new build.

​
Tagging a new release

Only maintainers with push access to the repository should tag releases. Verify each step carefully — the CI pipeline submits builds directly to the Chrome Web Store and AMO on tag push.
1

Start from a clean master branch

Make sure your working directory has no uncommitted changes and that you are on the master branch:
git checkout master
git status
git status should report a clean working tree before you proceed.
2

Update Firefox minimum version

Open firefox_manifest.json and update the strict_min_version field under browser_specific_settings.gecko to the current Firefox ESR version.Use the Firefox release calendar to find the latest ESR. This value must be kept current because AMO will eventually reject extensions where it is too low.
"browser_specific_settings": {
    "gecko": {
        "strict_min_version": "128.0"
    }
}
3

Run the release script

npm run release
The script will prompt you for:
  1. The new four-segment version number (e.g. 7.1.0.1). Rules to follow:
    • Only update major.minor.patch if the previous release was a stable release (i.e. you are starting a new beta series).
    • If the previous release was a beta, increment the build number by 1 and keep major.minor.patch the same.
    • If the previous release was stable, reset the build number to 1.
  2. The release name (e.g. Pensive Penguin). Only change this for major or minor version bumps; patch releases and beta iterations reuse the existing name.
The script automatically creates a commit and a local git tag.
4

Verify the release commit

Inspect the commit produced by the script:
git show HEAD
The diff should contain only version string changes in the manifest files (manifest.json, firefox_manifest.json). If any other files were changed, do not push — investigate and fix the issue first.
5

Push the commit and tag

git push && git push --tags
Pushing the tag triggers the CI pipeline. Beta tags are submitted to the beta listings only; stable tags update both the stable and beta listings (the beta listing receives a beta-flagged build of the same code).

​
What CI does after the tag push

Once your tag reaches GitHub, the pipeline:
  1. Checks out the tagged commit and sets BUILD_TYPE and BUILD_SHA appropriately.
  2. Runs npm run build to produce build/chrome and build/firefox artifacts.
  3. Submits the Chrome build to the Chrome Web Store.
  4. Submits the Firefox build to AMO (addons.mozilla.org).
You do not need to manually upload anything to the stores.
If the CI submission fails (e.g. due to a store policy change or a transient API error), check the GitHub Actions run for the tag. Rerunning the workflow is usually sufficient — you do not need to create a new tag.

Build docs developers (and LLMs) love

Get started for freeTalk to us