chore: bump to 0.2.0 and document everything shipped under the stale 0.1.0 string #5

Merged
mohlec merged 3 commits from chore/version-0.2.0 into main 2026-08-05 14:47:22 +00:00
Owner

Why

plugin.json has read 0.1.0 since 2026-06-02. CI derives the bundle version from that file, so every rolling build since — including all of the mobile board work and the Phase 6 notifications — has shipped as 0.1.0.

The practical consequence: mmctl plugin list reports 0.1.0 whether the server is running June code or July code. There is no way to tell what is deployed without checksumming binaries.

That is not hypothetical. Checking CT#137 today:

Marker string from notify.go Deployed binary latest release
30-minute reminder ABSENT PRESENT
New appointment assigned ABSENT PRESENT
dispatch-bot ABSENT PRESENT

Phase 6 has been built and released since 2026-07-04 and never deployed. Techs are not receiving appointment DMs or 30-minute reminders, and the version string gave no signal.

What this changes

  • plugin.json 0.1.0 -> 0.2.0
  • CHANGELOG.md — a real 0.2.0 entry covering everything since 0.1.0 (Phase 6 notifications, mobile board, server-rendering, KV session auth, CI rolling release, the HTML-injection and duplicate-constant fixes)
  • README.md — build example no longer hardcodes 0.1.0

No code changes. CI will produce com.ncwcom.slash-dispatch-0.2.0.tar.gz, and the deploy that follows will finally report a version that means something.

Follow-up worth doing separately

A one-time bump fixes today but not the pattern — the next commit that lands without a bump reintroduces the ambiguity. Options: have CI stamp the short commit into the bundled plugin.json version for rolling builds (0.2.0+abc1234 is valid semver build metadata, but needs checking against Mattermost's manifest validation first), or build with -buildvcs=true so the commit is embedded in the binary and provenance is checkable directly. Deliberately not doing either here — this repo builds only on push to main, so a mistake in either would not surface until after merge.

## Why `plugin.json` has read `0.1.0` since 2026-06-02. CI derives the bundle version from that file, so **every rolling build since — including all of the mobile board work and the Phase 6 notifications — has shipped as 0.1.0.** The practical consequence: `mmctl plugin list` reports `0.1.0` whether the server is running June code or July code. There is no way to tell what is deployed without checksumming binaries. That is not hypothetical. Checking CT#137 today: | Marker string from `notify.go` | Deployed binary | `latest` release | |---|---|---| | `30-minute reminder` | **ABSENT** | PRESENT | | `New appointment assigned` | **ABSENT** | PRESENT | | `dispatch-bot` | **ABSENT** | PRESENT | **Phase 6 has been built and released since 2026-07-04 and never deployed.** Techs are not receiving appointment DMs or 30-minute reminders, and the version string gave no signal. ## What this changes - `plugin.json` 0.1.0 -> **0.2.0** - `CHANGELOG.md` — a real 0.2.0 entry covering everything since 0.1.0 (Phase 6 notifications, mobile board, server-rendering, KV session auth, CI rolling release, the HTML-injection and duplicate-constant fixes) - `README.md` — build example no longer hardcodes `0.1.0` No code changes. CI will produce `com.ncwcom.slash-dispatch-0.2.0.tar.gz`, and the deploy that follows will finally report a version that means something. ## Follow-up worth doing separately A one-time bump fixes today but not the pattern — the next commit that lands without a bump reintroduces the ambiguity. Options: have CI stamp the short commit into the bundled `plugin.json` version for rolling builds (`0.2.0+abc1234` is valid semver build metadata, but needs checking against Mattermost's manifest validation first), or build with `-buildvcs=true` so the commit is embedded in the binary and provenance is checkable directly. Deliberately not doing either here — this repo builds only on push to `main`, so a mistake in either would not surface until after merge.
The version has read 0.1.0 since 2026-06-02 while main gained the entire
mobile board and Phase 6 notification work. Because CI derives the bundle
version from plugin.json, every rolling build has shipped as 0.1.0, so
`mmctl plugin list` could not distinguish a June build from a July one.
mohlec merged commit fd25cccc64 into main 2026-08-05 14:47:22 +00:00
mohlec deleted branch chore/version-0.2.0 2026-08-05 14:47:23 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
slash/slash-dispatch-plugin!5
No description provided.