diff --git a/CHANGELOG.md b/CHANGELOG.md index 55331e3..256974a 100644 --- a/CHANGELOG.md +++ b/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-.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-.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 diff --git a/README.md b/README.md index b7b32dd..88c22eb 100644 --- a/README.md +++ b/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 ``` --- diff --git a/SECURITY.md b/SECURITY.md index d91e094..07b87d9 100644 --- a/SECURITY.md +++ b/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 diff --git a/docs/install.md b/docs/install.md index 413a2fd..7fbb623 100644 --- a/docs/install.md +++ b/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 ` | serve HTTPS on this domain, certificate and renewal included | | `--tls-email ` | certificate contact (default: the admin email; `internal` self-signs) | | `--url ` | 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 ` | pin the files and image tag together. `v1.0.1` and `1.0.1` both work. Sticky — later runs stay on it | +| `--version ` | 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 ` | install here rather than `./forge-growth` | | `--admin-email ` | 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