reasampler/docs/product/versioning-and-release.md

Versioning & release — product notes

Framing behind two release-milestone (M11-adjacent) capabilities Daniel wants made concrete and decidable:

1. A release version scheme — so a "real" stable build can be deployed and identified.
2. A beta side-channel — so development can continue and a beta build run alongside the stable one without the beta clobbering the release.

This doc holds the why, the forks, and a recommendation. When Daniel picks, the tickable points land in PLAN.md and the deploy/build wiring hands off to dev-ops. This is a framing note; it changes no source or CMake.

Status: framed by product-designer (2026-07-26); all four forks settled by Daniel (2026-07-26). V1 approved as recommended (ext-state version stamp prioritized to the first wave); V2 plain -beta suffix (git describe decoration rejected); V3 recommendation accepted (console line + panel readout, about-box deferred); V4 reversed the recommendation — Daniel chose beta-in-isolation / full coexistence (separate binary, isolated ext-state namespace, isolated command-id prefix) rather than the branch-discipline/one-at-a-time path the note originally recommended. The "Recommendation" and "Open decisions" sections below have been superseded to reflect the settled state; each records what was chosen and why. Deploy/build wiring hands off to dev-ops.

Note on V4 phrasing (provisional). The-boss's read of "beta-in-isolation" as the separate-binary + isolated-namespace + isolated-command-id-prefix coexistence path is provisional pending a final confirm from Daniel. Written that way here; a minor correction is a cheap edit.

---

The one constraint that shapes everything: REAPER's startup dlopen

REAPER, at startup only, scans UserPlugins/ and dlopen()s every file matching reaper_*.dll|dylib|so, then calls each one's ReaperPluginEntry (CLAUDE.md §REAPER extension contract). Three consequences drive every decision below:

• Two matching files load simultaneously. If both reaper_reasampler.dll and reaper_reasampler_beta.dll sit in UserPlugins/, REAPER loads both — two independent extension instances in one REAPER process. This is the mechanism a beta side-channel would exploit, and also its central hazard.
• No hot reload. Deploy = copy the binary in, restart REAPER. Any scheme is "restart to pick up," never live-swap.
• Everything is process-global inside REAPER. Two coexisting instances share one REAPER, one Actions list, one project, one ext-state store. Anything keyed by a global string (command ids, ext-state namespace, docked-window identity) is a potential collision surface between the two.

Two sharp edges follow directly and recur throughout this note:

• The STABLE_FOREVER_STRING command-id contract (CLAUDE.md; main.cpp:41, prefix CEREBELLUM_REASAMPLER_). Command-id strings are minted once and never changed after shipping — user keybindings key off them. Two coexisting binaries that register the same id strings collide in REAPER's Actions list.
• The "reasampler" project ext-state namespace (shared by the banks, view_state, project_guid, tail_setting keys, plus the retired bank_index). Both binaries reading/writing the same namespace on the same open project means a beta can read — and rewrite — a stable project's saved bank/view state. Given the forward-only migrations already in the design (legacy bank_index retired after promotion; banks authoritative thereafter — CONTEXT.md §Multi-bank), a beta that writes a newer schema into a project a user then reopens in stable is a real corruption path, not a theoretical one.

Everything below is really about how much of that global surface a beta channel is allowed to touch.

---

Part 1 — Version scheme + where the version lives

What we have today

• No version anywhere. CMakeLists.txt:2 is project(reaper_reasampler LANGUAGES CXX) — no VERSION. The binary announces itself only as "ReaSampler loaded.\n" to the console (main.cpp:960). There is no number a user, a bug report, or a future migration can key off.
• The natural user-visible readout already exists: the docked LICE bank panel, and the console (ShowConsoleMsg). A version has cheap homes; none is wired.

The number itself (V1) — SETTLED (2026-07-26): semver, sourced from CMake; ext-state stamp lands ASAP / first wave

Decision (V1). Approved as recommended. Semver, single source of truth in CMake project(reaper_reasampler VERSION x.y.z), threaded into the binary. The "reasampler" ext-state writing-version stamp is prioritized to the first wave, not deferred — Daniel emphasized ASAP because every project saved without the stamp is harder to migrate later, so the migration seam must exist before more real projects accrue un-stamped state. Treat the stamp as an early, high-priority deliverable that ships with (or ahead of) the first versioned build.

Recommend semantic versioning (MAJOR.MINOR.PATCH) with the number's single source of truth in CMakeLists.txt via project(reaper_reasampler VERSION x.y.z), threaded into the binary as a compile definition and surfaced to the user.

Semver fits because ReaSampler already has the two events semver exists to signal, and they matter here specifically:

• MAJOR / MINOR track user-visible capability (a new pillar landing: Phase R prune, M9 slots).
• PATCH tracks fixes.
• Most importantly, ReaSampler carries persisted, migrating project state (the "reasampler" ext-state, forward-only migrations). A version stamped into the saved blob is what lets a future build say "this project was written by 1.4, I am 1.6, run the 1.4→1.6 migration" — or refuse gracefully. That is a concrete, already-latent need, not ceremony. Recommend stamping the writing version into the ext-state blob as part of whichever release wave ships (small addition to the persist section; a sibling schema/app_version field).

Source of truth: CMake project(VERSION). One number, in the build system, flowed outward — never hand-edited in a header. project(... VERSION x.y.z) populates PROJECT_VERSION / PROJECT_VERSION_MAJOR|MINOR|PATCH, which a target_compile_definitions (e.g. REASAMPLER_VERSION="…") threads into the binary. This is the standard CMake idiom and keeps the tag, the binary, and any about-string in lockstep from one edit.

Alternatives considered:

• Git-derived version (git describe --tags) baked at configure time. Pro: the build literally cannot disagree with the tag; encodes commits-since-tag + dirty state, which is excellent for a beta ("1.4.0-beta.3+7.gab12cd"). Con: needs git present at build and a tag discipline; a source tarball without .git builds "unknown." This was originally recommended for the beta suffix — Daniel rejected it (V2 settled below: a plain -beta suffix is more legible than a decorated git describe string). project(VERSION) still owns the release triple; the beta simply carries -beta. (See V2.)
• A hand-maintained version.h. Rejected — a second source of truth that drifts from the tag. The whole point of one source is that release can't ship a binary that lies about its number.
• Date-based / CalVer (2026.07). Coherent, but ReaSampler's changes are capability-shaped (pillars landing), not time-shaped, and CalVer says nothing about migration compatibility, which is the load-bearing use here. Semver earns its place; CalVer doesn't.

Where the user sees it (V3) — SETTLED (2026-07-26): panel readout + startup log; about box deferred

Decision (V3). Recommendation accepted (Daniel deferred to product-designer judgment — "whatever"). Startup console line ("ReaSampler x.y.z loaded") + a bank-panel version/channel readout ship; the about-box stays deferred. Panel placement (header corner / footer / folded into existing chrome) remains a small residual polish call, same class as the settled active-bank-indicator placement.

Three candidate homes, cheap to expensive:

1. Startup console line — upgrade "ReaSampler loaded.\n" to "ReaSampler x.y.z loaded.\n". Nearly free, and it lands the version in exactly the place a user copies from when filing a bug. Do this regardless of the other choices.
2. Bank-panel readout — a small version string in the docked LICE panel (header corner or footer, near the existing tail toggle / mode switch). Always visible, no new window, matches the LICE-drawn house style. Recommend this as the primary user-facing home.
3. An "about" action / dialog — a bindable ReaSampler: about that pops version + build channel + build hash. More than the moment needs; a SWELL dialog is real surface to maintain. Defer — the panel readout + console line cover the actual need (identify the running build). Pick this up only if a beta channel makes "which build am I running" a frequent question.

Recommendation: (1) + (2) now, (3) deferred. The version wants to be visible passively (panel) and copyably (console), and a beta channel makes the panel readout do double duty as the channel indicator (Part 2).

Open decision V3 for Daniel: panel placement — header corner vs. footer strip vs. folded into the existing mode-switch/tail-toggle chrome. This is a small panel polish call, same class as the settled "active-bank indicator placement" residual.

---

Part 2 — Beta side-channel

The goal: keep shipping a stable build users depend on, while running a beta of in-progress work alongside it, so the beta can be exercised in real projects without the beta's newer/rougher state clobbering the stable install or stable projects.

The design axis is coexistence: must stable and beta load into the same REAPER at the same time (true side-by-side), or is it enough to run one at a time with clean, safe switching? That axis splits the options.

Option A — Separate binary name, both load simultaneously (true coexistence)

Ship reaper_reasampler_beta.dll next to reaper_reasampler.dll. REAPER loads both; the user has a stable ReaSampler and a beta ReaSampler live in one session.

This is the most powerful shape — and the most dangerous, because of the three global-collision surfaces the startup-dlopen constraint creates. A separate binary name alone does not isolate them; it just makes them coexist. For Option A to be safe, three things must diverge in lockstep, not just the filename:

1. Command-id strings must diverge. Both binaries register actions; if the beta mints CEREBELLUM_REASAMPLER_CAPTURE_TRACK too, REAPER's Actions list has two entries claiming one id — collision, and the STABLE_FOREVER_STRING contract is violated. The beta needs its own prefix (e.g. CEREBELLUM_REASAMPLER_BETA_). Sharp edge: that means the beta's ids are a distinct forever-family — a user's beta keybindings won't carry to stable, and vice versa. That is arguably correct (they're different installs), but it must be a deliberate decision, because once the beta ships those beta ids are also forever-stable. You are minting a second permanent id namespace, not a throwaway.

2. The ext-state namespace must diverge — or the beta corrupts stable projects. This is the severe one. If the beta writes banks/view_state under "reasampler", a project saved by the beta carries beta-schema state that stable then reads (and the forward-only migration may have already retired the key stable expected). The beta must write under its own namespace (e.g. "reasampler_beta"). Consequence, and it cuts both ways: a beta cannot see a stable project's bank (different namespace), so testing the beta against a real populated project means the bank looks empty until re-captured. That is the price of isolation, and it is the right price — a beta that shares stable's namespace is a data-loss bug waiting to happen. This divergence is non-negotiable if Option A is chosen.

3. The docked-window / docker identity should diverge, so the two panels are distinguishable and don't fight over one dock slot. Lower-severity (a UX annoyance, not corruption), but part of the same "everything global must fork" picture.

Net: Option A delivers genuine side-by-side at the cost of forking every global identity the extension owns. It is a compile-time-parameterized second product, not a branch artifact — which points straight at Option C as the mechanism for how you'd actually build it.

Option B — One binary, branch discipline, one installed at a time

dev → beta builds, main → release builds; the version string carries a -beta/-dev suffix so the running build self-identifies; only one is installed at a time. No coexistence — you swap the binary and restart REAPER to change channels.

• Pro: zero collision surface. Same command ids, same ext-state namespace, one file — because only one is ever loaded. Nothing forks. Simplest by a wide margin.
• Pro: matches the repo's existing branch reality (dev is the working branch, main the release branch — visible in the current git state).
• Con: no true side-by-side. To A/B stable against beta you swap files and restart. For a solo developer this is often entirely fine — the friction is a file copy + restart, not a corruption risk.
• Sharp edge (the reason it's still not free): if the beta writes a newer/experimental ext-state schema into a real project, then you swap back to stable and open that project, stable reads beta-written state. One-binary branch discipline removes the simultaneous collision but not the sequential one — the project file is the shared surface across a channel swap. Mitigation: either (a) keep the beta strictly schema-compatible with stable (no ext-state shape changes on the beta channel — often true, since most beta work is behavior, not persistence), or (b) accept "don't open beta-touched real projects in stable" as a discipline, or (c) stamp the writing version into the blob (V1) so stable can at least detect and refuse/migrate rather than silently mis-read.

Option C — Compile-time build flag (the mechanism, usable under A or B)

A CMake/preprocessor switch (-DREASAMPLER_CHANNEL=beta) that, in one build tree, sets: output name, command-id prefix, ext-state namespace, version suffix, and the panel channel indicator. This is not really a third strategy — it's how you implement the divergence Option A demands, or how you stamp the suffix Option B wants. It's the knob; A and B are policies for the knob.

• Under Option A, the flag is what forks the two binaries from one source cleanly — flip REASAMPLER_CHANNEL, get the beta's name/prefix/namespace/suffix as a coordinated set, so the three-way divergence can't get out of sync by hand.
• Under Option B, the flag just sets the suffix + a channel tag; name/prefix/ namespace stay shared because only one loads.

The flag is worth having either way because it makes "what makes a beta a beta" a single, auditable definition instead of scattered #ifdefs.

Decision (V4) — SETTLED (2026-07-26): Option A — beta-in-isolation / full coexistence

This reverses the note's original recommendation. The note originally recommended Option B (branch discipline, one installed at a time) built on the Option C channel flag, with Option A (true simultaneous coexistence) seam-designed but deferred. Daniel chose the coexistence path instead. The superseded recommendation prose is retained below the decision (struck through in intent, kept for the reasoning trail) so a future reader sees what was weighed; the decision here governs.

Settled shape: beta ships as a separate, fully isolated binary that coexists with stable in one REAPER. Concretely, all three global identities fork (this is Option A, built through the Option C compile-time channel flag as the mechanism):

• Separate binary — reaper_reasampler_beta alongside reaper_reasampler, so REAPER's startup dlopen loads both and the user runs stable and beta side-by-side.
• Isolated ext-state namespace — the beta writes under its own namespace (e.g. "reasampler_beta"), distinct from stable's "reasampler", so a beta can never read or rewrite a stable project's saved bank/view/tail state. The price is accepted: a beta does not see a stable project's bank (it looks empty until re-captured under the beta namespace). That is the correct price — isolation over convenience.
• Isolated forever-stable command-id prefix — the beta mints its own prefix (e.g. CEREBELLUM_REASAMPLER_BETA_), so beta and stable actions never collide in REAPER's one Actions list and their keybindings stay independent.

The compile-time channel flag (-DREASAMPLER_CHANNEL=beta, Option C) remains the implementation mechanism: one flip coordinates output name + command-id prefix + ext-state namespace + -beta version suffix + panel channel badge as a single auditable definition, so the three-way divergence can't drift by hand.

The two permanent commitments this locks in (recorded honestly)

Choosing coexistence over the deferred-seam path accepts two commitments that are permanent once the first beta ships — exactly the prices the original recommendation flagged as reasons to defer:

1. A second forever-stable command-id prefix. The beta's ids are their own forever-family (STABLE_FOREVER_STRING contract applies to them too the moment a beta ships). Beta keybindings do not carry to stable and vice versa. Irreversible.
2. A second ext-state namespace. "reasampler_beta" is permanent — and its isolation means beta and stable never share a project's bank. This is the safety property, but it is also a fork of your own test data that you own from day one.

Both are deliberate and accepted; recorded here so no future reader treats them as oversights.

Deploy / CD implication (dev-ops hand-off)

The build now produces two named artifacts per platform — reaper_reasampler (stable) and reaper_reasampler_beta (beta) — selected by REASAMPLER_CHANNEL. That is a dev-ops handoff: the pipeline builds, names, and publishes both channels (three platform artifacts each). See Part 3.

The ext-state safety property, now settled by isolation

The sharp edge the original note flagged as the genuine V4 sub-decision — can a beta write experimental ext-state that a stable build later reads? — is resolved by the isolated namespace: no. Beta writes only under "reasampler_beta"; stable reads only "reasampler". There is no shared-project corruption path across the channels, neither simultaneous nor sequential. V1's writing-version stamp still lands first-wave (it guards within-channel forward migration — stable-1.4 reading stable-1.6 state — which isolation does not address), but it is no longer load-bearing for cross-channel safety.

---

Superseded recommendation (retained for the reasoning trail)

The following was the note's original V4 recommendation. It is superseded by the settled decision above (Daniel chose coexistence). Kept because the trade-off reasoning — the permanent-price argument in particular — is what the decision was weighed against.

Start with Option B (branch discipline, one at a time) implemented through a compile-time channel flag (Option C): ship stable as reaper_reasampler from main; build beta from dev via the channel flag with only a -beta suffix + panel badge; do not fork the command-id prefix or ext-state namespace, since under B only one binary loads and forking prematurely commits a second forever-stable id family for no gain. Then treat Option A (true coexistence) as a later, deliberate upgrade if swap-and-restart proved too slow — the upgrade being clean precisely because B was built on the channel flag (flip A on = extend the flag to fork name + _BETA_ prefix + "reasampler_beta" namespace). The stated reason to defer A: it forces minting a second permanent command-id namespace and a second ext-state namespace on day one — a large, permanent price for a convenience (simultaneous compare) that might not be needed. Daniel weighed that price and chose to pay it: the value of running stable and beta side-by-side, with hard isolation guaranteeing a beta can never corrupt stable state, outweighed avoiding the two permanent commitments.

---

Part 3 — Deploy / CD touchpoints (hand-off to dev-ops)

Framing only — the actual pipeline is dev-ops's to author. The strategy above implies these touchpoints:

• Tag → version. Release is cut from a git tag on main; project(VERSION) is bumped to match the tag (or the tag is derived from it — pick one direction and keep it one-way). Beta builds from dev carry git describe in the suffix.
• Channel is a build parameter. -DREASAMPLER_CHANNEL=release|beta selects the suffix/badge now (Option B) and, if Option A is ever turned on, the output name/prefix/namespace too. One flag, one definition of "what is a beta."
• Artifact per platform. The binary is reaper_*.dll|.dylib|.so; the macOS/Linux builds need the SWELL resgen step (CLAUDE.md §SWELL dialog resources) baked into the pipeline. Three platform artifacts per channel per release.
• Install is copy-in + restart (no hot reload). A release "deploy" is publishing the artifact for the user to drop into UserPlugins/; there is no server-side rollout. Any auto-update story is out of scope here and would be its own note.
• The ext-state version stamp (V1) is the one piece of forward-compatibility plumbing the pipeline should ensure ships in the first versioned release, so every subsequent build can reason about older saved state.

---

Settled decisions (all four — Daniel, 2026-07-26)

• V1 — version scheme: APPROVED as recommended. Semver, single source of truth in CMake project(reaper_reasampler VERSION x.y.z), threaded into the binary. The "reasampler" ext-state writing-version stamp is prioritized to the first wave — every project saved without it is harder to migrate later, so the migration seam lands early, not deferred.
• V2 — beta suffix: plain -beta. project(VERSION) owns the release triple; beta builds carry a -beta suffix. The git describe decoration was considered and rejected for legibility ("-beta is better than a random string").
• V3 — user-visible home: recommendation accepted. Startup console line ("ReaSampler x.y.z loaded") + a bank-panel version/channel readout; about-box deferred. Panel placement remains a small residual polish call.
• V4 — beta channel shape: BETA-IN-ISOLATION (full coexistence). Reverses the original recommendation. Beta ships as a separate binary (reaper_reasampler_beta) with an isolated ext-state namespace and an isolated forever-stable command-id prefix, so stable and beta install and run side-by-side with no shared-state corruption path. Locks in two permanent commitments — a second forever-stable command-id prefix and a second ext-state namespace — both accepted. Dev-ops implication: the build now produces two named artifacts (stable + beta) per platform.