{"id":"69ecef9a60bb8b34fce600ad","title":"Release Notes And Versioning","path":"how-to/technical-articles/2026-04-21-using-ramblers-salesforce-mock/release-notes-and-versioning","contentMarkdown":"# 21-Apr-2026 — Release notes and versioning\n\n_____\n\nThe mock advertises its own version and recent commit history so consumers can tell at a glance which build is deployed and what's changed since they last integrated. Useful when a downstream test starts behaving differently and you need to know whether the mock changed underneath you.\n\n[← Back to the overview](https://ngx-ramblers.org.uk/how-to/technical-articles/2026-04-21-using-ramblers-salesforce-mock)\n\n![](https://ngx-ramblers.org.uk/api/aws/s3/site-content/73c7aa7b-c526-415e-8474-8e5c292f79c6.png)\n\n*The release notes view shows the last fifty commits to the deployed server, with author, date, subject, and body.*\n\n## Release notes view\n\nSign in, then click **Release notes** in the header (or visit [`/admin/release-notes`](https://salesforce-mock.ngx-ramblers.org.uk/admin/release-notes) directly). It shows the last fifty commits to the server, each with author, date, subject, and body — the same content you'd see from `git log` on the deployment box.\n\nUseful for:\n\n- Confirming a fix you raised has actually been deployed\n- Finding the commit that introduced a behaviour you've just noticed\n- Spot-checking what's been merged since your last integration test\n\n## Version stamp\n\nThe footer of every signed-in admin page shows `version · `. Same data is exposed publicly (no authentication required) at:\n\n```sh\ncurl -sS https://salesforce-mock.ngx-ramblers.org.uk/admin/api/version | jq .\n```\n\n```json\n{\n \"version\": \"0.4.0\",\n \"gitSha\": \"fb1021c\",\n \"generatedAt\": \"2026-04-21T12:34:56.789Z\"\n}\n```\n\nPublic access is deliberate — it lets a downstream CI job assert \"the mock is at least version X\" before running an integration suite, without needing to mint a token first.\n\n## Release notes API\n\nSame data the in-browser view consumes, available as JSON for the curious or for downstream tooling:\n\n```sh\nTOKEN_COOKIE=... # see /admin/api/login\ncurl -sS -b \"$TOKEN_COOKIE\" https://salesforce-mock.ngx-ramblers.org.uk/admin/api/release-notes | jq .\n```\n\nThis endpoint requires an authenticated operator session (same as the admin UI); it is not exposed to the public.\n\n## How the data gets there\n\nThe build pipeline writes a `dist/build-info.json` snapshot during `npm run build` — version from `package.json`, git SHA, generation timestamp, and the last fifty commits. The server reads that file at startup and caches it for the lifetime of the process.\n\nIn dev (`npm run dev`), the snapshot file usually doesn't exist yet, so the server falls back to running `git log` live against the working directory. That keeps the dev experience honest — what you see locally is exactly the same shape consumers will see in production.\n\nWhen you bump version, change the `version` field in `package.json`, rebuild, and redeploy — the new value flows through automatically.\n\n## Next\n\n[**Root operator tasks →**](https://ngx-ramblers.org.uk/how-to/technical-articles/2026-04-21-using-ramblers-salesforce-mock/root-operator-tasks)","contentHtml":"

21-Apr-2026 — Release notes and versioning

\n
\n

The mock advertises its own version and recent commit history so consumers can tell at a glance which build is deployed and what's changed since they last integrated. Useful when a downstream test starts behaving differently and you need to know whether the mock changed underneath you.

\n

← Back to the overview

\n

\"\"

\n

The release notes view shows the last fifty commits to the deployed server, with author, date, subject, and body.

\n

Release notes view

\n

Sign in, then click Release notes in the header (or visit /admin/release-notes directly). It shows the last fifty commits to the server, each with author, date, subject, and body — the same content you'd see from git log on the deployment box.

\n

Useful for:

\n\n

Version stamp

\n

The footer of every signed-in admin page shows version <semver> · <gitSha>. Same data is exposed publicly (no authentication required) at:

\n
curl -sS https://salesforce-mock.ngx-ramblers.org.uk/admin/api/version | jq .\n
\n
{\n  "version": "0.4.0",\n  "gitSha": "fb1021c",\n  "generatedAt": "2026-04-21T12:34:56.789Z"\n}\n
\n

Public access is deliberate — it lets a downstream CI job assert "the mock is at least version X" before running an integration suite, without needing to mint a token first.

\n

Release notes API

\n

Same data the in-browser view consumes, available as JSON for the curious or for downstream tooling:

\n
TOKEN_COOKIE=...   # see /admin/api/login\ncurl -sS -b "$TOKEN_COOKIE" https://salesforce-mock.ngx-ramblers.org.uk/admin/api/release-notes | jq .\n
\n

This endpoint requires an authenticated operator session (same as the admin UI); it is not exposed to the public.

\n

How the data gets there

\n

The build pipeline writes a dist/build-info.json snapshot during npm run build — version from package.json, git SHA, generation timestamp, and the last fifty commits. The server reads that file at startup and caches it for the lifetime of the process.

\n

In dev (npm run dev), the snapshot file usually doesn't exist yet, so the server falls back to running git log live against the working directory. That keeps the dev experience honest — what you see locally is exactly the same shape consumers will see in production.

\n

When you bump version, change the version field in package.json, rebuild, and redeploy — the new value flows through automatically.

\n

Next

\n

Root operator tasks →

\n"}