Decision: adopt B+C+D for version consistency (manifest-derived build version)

[chtaylo3]

Type: Risk-based architecture decision (recorded for traceability; resolved on creation).

Context

The release version flows from .release-please-manifest.json -> CMakeLists.txt project(VERSION) -> embedded DLL VERSIONINFO (version.rc/version.h) and, separately, into the release-zip filename. Today these are linked only by release-please's best-effort text substitution of the # x-release-please-version marker, which can silently no-op and ship a zip whose name disagrees with the DLL's embedded version (and which Plugins Admin / nppPluginList would reject).

Decision

Adopt B + C + D (over the lighter A+C) to eliminate the drift classes structurally rather than only alarming on them:

• B - CMake derives PROJECT_VERSION from .release-please-manifest.json at configure time; remove CMakeLists.txt from release-please extra-files and drop the marker. Strip any prerelease/build suffix to stay project(VERSION)-legal.
• C - publish job asserts the built DLL's FileVersion equals the release-please version (4-part padded) and fails before going live.
• D - package.ps1 derives -Version from the built DLL (normalized to 3-part) instead of an independent argument.

Trade-off accepted. Larger surface than A+C, and B sits on the always-run configure path - so B will be landed in its own PR behind green CI before being relied upon.

Future error conditions to watch for

1. Missing/renamed .release-please-manifest.json in any build context (CI, CodeQL build, release publish, or source-only/port consumption) -> configure FATAL_ERROR. B must carry a safe fallback.
2. Prerelease/build-suffixed version (e.g. a manual release-as) -> project(VERSION ...) rejects non-numeric; B's suffix-stripping must handle it or fail with a clear message.
3. B on the shared configure path: a parse bug blocks all PR merges via required status checks, not just releases.
4. 3-part vs 4-part normalization in C (0.2.0 vs 0.2.0.0) - mismatch here causes false-negative release failures.
5. C halts publish after the tag + draft release already exist (approval ci: Bump the actions group across 1 directory with 5 updates #1) -> documented recovery: delete draft release + tag, fix, re-run, re-grant the release environment approval.
6. vcpkg.json is still updated by a separate release-please JSON updater -> can drift from the manifest (low risk; unused downstream). Consider a configure-time equality assertion.
7. Sole CODEOWNERS (* @chtaylo3) -> each PR (these included) follows the standard self-approval / admin-bypass path.
8. Stale build cache serving an old DLL -> caught by C; B+D alone would not catch it.

Resolution

Decision recorded; implementing B+C+D. Closing as resolved.

[chtaylo3]

Resolved: decision recorded above. Proceeding to implement B+C+D (landing B behind green CI first).

[chtaylo3]

Implemented as three stacked PRs (merge in order):

1. feat(plugin): embed VERSIONINFO and ship Notepad++-compliant release zips #7 — foundation: embed VERSIONINFO + Notepad++-compliant packaging (all CI green).
2. build: derive PROJECT_VERSION from release-please manifest (#6, B) #8 — B: derive PROJECT_VERSION from .release-please-manifest.json (warn+fallback on the configure path).
3. ci: gate release on embedded DLL version (C) + derive zip version from binary (D) #9 — C + D: publish-time version gate + binary-derived zip version.

Per the decision, B (#8) lands in its own PR behind green CI: it will run full CI against main once #7 merges and it auto-retargets. A real bug was caught implementing C — a recursive DLL search had matched a stale Debug build; C and packaging now read the deterministic Release\FixParser.dll.