Release 2.0.0

CHANGELOG.md

@@ -15,39 +15,11 @@ Upgrade with `./scripts/install.sh` (or `./install.sh` on an images install), wh
 re-run and leaves `.env` and your database alone. Pin to a specific release with
 `./install.sh --version vX.Y.Z`.
 
-## [1.0.1] — 2026-08-18
-
-Published as multi-architecture images tagged `1.0.1`, `1.0` and `1`.
-
-### Fixed
-
-- **`--version` now accepts the version in the form the install reports it.** Git tags here are
-  `v1.0.0`; the image tag is `1.0.0` — `docker/metadata-action` strips the leading `v`, which is the
-  conventional form for a container tag. `install.sh` converted the git form to the image form but
-  not the reverse, so `--version 1.0.0` — the form `.env`, `docker ps` and the release notes all show,
-  and therefore the form somebody copies back — asked `raw.githubusercontent` for a ref that does not
-  exist and failed with "the version '1.0.0' does not exist", blaming the release for a missing
-  character. A fully-qualified `refs/tags/v1.0.0` was worse: that ref IS servable, so the files
-  pinned and only the image tag was discarded as unusable, leaving 1.0.0's compose file driving
-  `latest` images. Both halves pin now, or neither.
-- **The `v1.0.0` tag could not install itself.** The strip in the other direction landed after the
-  tag was cut, so `--version v1.0.0` — the exact command the README gave for a server — passed
-  `v1.0.0` through as an image tag and `docker compose pull` answered `manifest unknown`: a message
-  about a registry, produced by a value that came out of a git tag. This is the release that carries
-  the fix, which is why it exists.
-
-### Added
+## [Unreleased]
 
-- **The install bundle now lives in the repository** at `dist/forge-growth-<version>.zip`, as well as
-  being attached to the release. Two hosts rather than one, for the same reason `install.sh` keeps a
-  local copy of a file it cannot download: the case worth planning for is GitHub rate-limiting or a
-  releases page that will not load.
-- **A one-command server install at the top of the README.** The route for a machine that already has
-  Docker was buried below three platform-by-platform sections it does not need. It now leads, with the
-  two prerequisites that actually fail it — DNS already pointing at the machine, ports 80 and 443
-  free — named next to the command rather than further down.
+## [2.0.0] — 2026-10-18
 
-## [Unreleased]
+Published as multi-architecture images tagged `2.0.0`, `2.0` and `2`.
 
 Brings in two months of work from the internal build. **This is a major release**: it removes
 three features and their data, so read the upgrade notes before re-running the installer.
@@ -148,6 +120,38 @@ three features and their data, so read the upgrade notes before re-running the i
   DB-backed (was "255 tests, 92"), and a pinned-install example that named `v1.4.0`, a release that
   never existed.
 
+## [1.0.1] — 2026-08-18
+
+Published as multi-architecture images tagged `1.0.1`, `1.0` and `1`.
+
+### Fixed
+
+- **`--version` now accepts the version in the form the install reports it.** Git tags here are
+  `v1.0.0`; the image tag is `1.0.0` — `docker/metadata-action` strips the leading `v`, which is the
+  conventional form for a container tag. `install.sh` converted the git form to the image form but
+  not the reverse, so `--version 1.0.0` — the form `.env`, `docker ps` and the release notes all show,
+  and therefore the form somebody copies back — asked `raw.githubusercontent` for a ref that does not
+  exist and failed with "the version '1.0.0' does not exist", blaming the release for a missing
+  character. A fully-qualified `refs/tags/v1.0.0` was worse: that ref IS servable, so the files
+  pinned and only the image tag was discarded as unusable, leaving 1.0.0's compose file driving
+  `latest` images. Both halves pin now, or neither.
+- **The `v1.0.0` tag could not install itself.** The strip in the other direction landed after the
+  tag was cut, so `--version v1.0.0` — the exact command the README gave for a server — passed
+  `v1.0.0` through as an image tag and `docker compose pull` answered `manifest unknown`: a message
+  about a registry, produced by a value that came out of a git tag. This is the release that carries
+  the fix, which is why it exists.
+
+### Added
+
+- **The install bundle now lives in the repository** at `dist/forge-growth-<version>.zip`, as well as
+  being attached to the release. Two hosts rather than one, for the same reason `install.sh` keeps a
+  local copy of a file it cannot download: the case worth planning for is GitHub rate-limiting or a
+  releases page that will not load.
+- **A one-command server install at the top of the README.** The route for a machine that already has
+  Docker was buried below three platform-by-platform sections it does not need. It now leads, with the
+  two prerequisites that actually fail it — DNS already pointing at the machine, ports 80 and 443
+  free — named next to the command rather than further down.
+
 ## [1.0.0] — 2026-08-17
 
 First tagged release. Everything below is what `v1.0.0` contains, not a diff against a previous
@@ -269,5 +273,7 @@ Published as multi-architecture images (`linux/amd64` and `linux/arm64`) at
 - Playwright end-to-end tests are not run in CI — they need the full stack and browser binaries, so
   run them locally against a live install.
 
-[Unreleased]: https://github.com/Forgemind-git/ForgeGrowth-OSS/compare/v1.0.0...HEAD
+[Unreleased]: https://github.com/Forgemind-git/ForgeGrowth-OSS/compare/v2.0.0...HEAD
+[2.0.0]: https://github.com/Forgemind-git/ForgeGrowth-OSS/compare/v1.0.1...v2.0.0
+[1.0.1]: https://github.com/Forgemind-git/ForgeGrowth-OSS/compare/v1.0.0...v1.0.1
 [1.0.0]: https://github.com/Forgemind-git/ForgeGrowth-OSS/releases/tag/v1.0.0

README.md

@@ -34,8 +34,8 @@ further calls to Meta.
 ### Already on a server with Docker? One command.
 
 ```bash
-bash -c "$(curl -fsSL https://raw.githubusercontent.com/Forgemind-git/ForgeGrowth-OSS/v1.0.1/scripts/install.sh)" -- \
-  --version v1.0.1 --domain crm.example.com --yes
+bash -c "$(curl -fsSL https://raw.githubusercontent.com/Forgemind-git/ForgeGrowth-OSS/v2.0.0/scripts/install.sh)" -- \
+  --version v2.0.0 --domain crm.example.com --yes
 ```
 
 Swap `crm.example.com` for your domain. That single command is the entire install: it pulls the
@@ -156,8 +156,8 @@ bash -c "$(curl -fsSL https://raw.githubusercontent.com/Forgemind-git/ForgeGrowt
 **On a server with a real domain**, pinned to a release and asking nothing at all:
 
 ```bash
-bash -c "$(curl -fsSL https://raw.githubusercontent.com/Forgemind-git/ForgeGrowth-OSS/v1.0.1/scripts/install.sh)" -- \
-  --version v1.0.1 --domain crm.example.com
+bash -c "$(curl -fsSL https://raw.githubusercontent.com/Forgemind-git/ForgeGrowth-OSS/v2.0.0/scripts/install.sh)" -- \
+  --version v2.0.0 --domain crm.example.com
 ```
 
 ---

SECURITY.md

@@ -8,16 +8,16 @@ unless you go looking for one. Watch this repository's releases if you run it in
 
 | Version | Supported |
 |---|---|
-| `1.0.x` | ✅ Security fixes |
+| `2.0.x` | ✅ Security fixes |
+| `1.0.x` | ❌ Upgrade to 2.0 — see the upgrade notes in `CHANGELOG.md` |
 | `main` | ✅ Fixes land here first |
-| Anything older | ❌ Nothing older exists yet — `v1.0.0` is the first tagged release |
 
 There is no long-term-support branch. The upgrade path is to re-run the installer, which is safe to
 re-run and leaves `.env` and your database alone:
 
 ```bash
 ./install.sh                  # move to the current release
-./install.sh --version v1.0.0 # or pin to a specific one
+./install.sh --version v2.0.0 # or pin to a specific one
 ```
 
 ## Reporting a vulnerability

docs/install.md

@@ -182,12 +182,12 @@ It asks one question — the address people will use — and derives everything
 What you want on a server you are handing to somebody:
 
 ```bash
-bash -c "$(curl -fsSL https://raw.githubusercontent.com/Forgemind-git/ForgeGrowth-OSS/v1.0.1/scripts/install.sh)" -- \
-  --version v1.0.1 --domain crm.example.com
+bash -c "$(curl -fsSL https://raw.githubusercontent.com/Forgemind-git/ForgeGrowth-OSS/v2.0.0/scripts/install.sh)" -- \
+  --version v2.0.0 --domain crm.example.com
 ```
 
 **Both halves of the pinned form matter.** The URL fixes which *script* runs; `--version` fixes what
-that script then downloads and pulls. Pin only one and you get a v1.0.1 script that fetches `main`.
+that script then downloads and pulls. Pin only one and you get a v2.0.0 script that fetches `main`.
 
 Give it a domain whose DNS already points at the machine and it obtains a Let's Encrypt certificate
 on the way up, then **verifies the certificate actually works** before reporting success.
@@ -271,7 +271,7 @@ pressing return. To skip them:
 | `--domain <host>` | serve HTTPS on this domain, certificate and renewal included |
 | `--tls-email <addr>` | certificate contact (default: the admin email; `internal` self-signs) |
 | `--url <origin>` | public origin the browser will use; sets CORS. **Include the port** if people reach it on one — `http://203.0.113.10:8080`, not `http://203.0.113.10` |
-| `--version <ref>` | pin the files and image tag together. `v1.0.1` and `1.0.1` both work. Sticky — later runs stay on it |
+| `--version <ref>` | pin the files and image tag together. `v2.0.0` and `2.0.0` both work. Sticky — later runs stay on it |
 | `--images` / `--source` | published images, or build from this checkout |
 | `--dir <path>` | install here rather than `./forge-growth` |
 | `--admin-email <addr>` | first-run admin |
@@ -470,7 +470,7 @@ overwritten — only empty or placeholder values are filled in — and every mig
 ```bash
 ./install.sh                    # images install: re-fetch, pull, restart
 git pull && ./scripts/install.sh   # source install
-./install.sh --version v1.0.1   # move deliberately, and stay there
+./install.sh --version v2.0.0   # move deliberately, and stay there
 ```
 
 A pinned install **stays pinned** — the version is remembered in `.forgegrowth-install`, so