Retire package-version bump and synchronization automation #135

Goal

Retire package-release version bookkeeping now that consumers adopt this repository by a pinned Git commit rather than new npm/PyPI releases.

The compatibility identity should be the source revision, not synchronized TypeScript/Python package version strings. Keep only the metadata needed to build/install locally. Optional GitHub tags/releases may remain human-readable milestones without requiring manifest bumps.

This is a separate, focused cleanup from S2 (#132, implementation #134). Do not fold versioning changes into the settings/lifecycle characterization PR.

Context and current implementation

The packages already share one synchronized version; this is not a request to merge two independent semantic-version policies. The unnecessary work is maintaining that version across manifests and gating ordinary source changes on release bookkeeping.

The README and contribution guide say that packages are no longer published and submodule updates are commit-based, but the repository still contains:

Inspection baseline: c064e40cdcf8478c841c265a5551b40f4157ce80. Relevant sources:

• Weekly bump workflow
• PR version validation and duplicate version check
• Version synchronization scripts
• Contribution/release documentation
• Default server metadata lookup
• Commit-based consumer updates

Proposed implementation

1. Remove automatic release-version maintenance. Retire the weekly patch-bump workflow and both manifest-version consistency workflows. Preserve build, lint, test, security, labeling and dependency-update checks.

2. Audit required checks before removing their producers. Inspect repository branch protection/rulesets for the two version-check contexts. Coordinate any required administrative change so merges do not wait forever for a deleted check. If neither is required, record that finding. Do not silently change unrelated protection.

3. Remove obsolete synchronization machinery and documentation. Delete unused version bump/sync/validation helpers and remove the root VERSION file if its remaining purpose is only that retired workflow. Check all references first. Update contribution/release instructions to explain commit-based adoption and optional milestone tags, without a required package-version bump.

4. Preserve valid local installation metadata. Keep the private npm and setuptools manifests and any fields their build/install tools need. The smallest initial change is to leave existing valid version values fixed rather than resetting them just for cosmetic consistency. Do not replace removed CI with another mandatory mechanism that synchronizes these numbers. Update lockfile metadata only if a deliberate manifest change requires it.

5. Handle diagnostic identity deliberately. Do not accidentally break importlib.metadata, the default server constructor or startup diagnostics while simplifying metadata. Preserving the existing reported version initially is acceptable. If adding source-revision diagnostics, capture the revision at build/bundle time and ship it with the artifact; an installed extension must not need Git, a .git directory or network access to start. Any change to reported server identity must be documented and tested.

6. Use provenance, not equal versions, as the architectural direction. Both runtimes in an extension should come from its intended common source revision. Reliable build invalidation and artifact-provenance enforcement belong to roadmap S4; reuse that work where available rather than turning this cleanup into a second build/canary framework. Explicitly document any remaining provenance follow-up.

Consumer sequencing caveat

At the architecture snapshot, Black (cf1e9a6c33a0dad41b5f499ee5efa25af2acaf38) still locked the published npm package to 0.8.2 while using Python from a shared submodule. The other four inspected extensions used source file dependencies for TypeScript.

Recheck current consumer state before implementation. Black's source-consumption migration (roadmap B0) must happen before declaring the ecosystem entirely source-only. Retiring dead automation can be independent if it does not break existing consumers, but do not assume permission to delete/change package identity or necessary metadata while registry-based adoption remains. Keep the Black migration in its own consumer PR.

Concrete examples

Ordinary source update: no release bookkeeping

Before:
  Consumer common submodule = commit A
  Local npm/Python metadata has valid fixed versions

After:
  Consumer common submodule = commit B
  Both runtimes are built/bundled from B
  No VERSION, package.json or pyproject.toml version bump is required
  Normal build/lint/test checks still run

Equal versions do not establish artifact compatibility

TypeScript artifact source = commit A, package metadata = 0.8.3
Python artifact source     = commit B, package metadata = 0.8.3

Old version comparison: passes, despite mixed revisions
Intended S4 provenance check: detects the source mismatch

Do not introduce a new release bump to solve this example; source/build provenance is the relevant invariant.

Optional milestone

A maintainer may tag a reviewed commit and write GitHub release notes. The tag is informational: it does not require updating package versions, publishing a package, or trigger/gate Dependabot submodule adoption. Keep existing tags/releases and historical changelog entries intact.

Acceptance criteria and validation

• No scheduled weekly package-version bump PRs remain.
• Ordinary PRs are no longer gated on synchronized manifest version strings.
• Required-check configuration has been audited/coordinated; no deleted check remains a merge blocker.
• Unused version scripts/root version state and stale contribution instructions are removed or explicitly justified.
• Local TypeScript builds and Python installation/bundling remain valid; necessary package metadata and private-package safeguards remain.
• The default Python server still starts and exposes intentional diagnostic identity without runtime Git/network requirements.
• Standard tests, lint, build and dependency-update automation are preserved.
• Documentation names the pinned source commit as adoption identity and explains optional milestone tags.
• The PR records the current Black adoption state and any prerequisite/follow-up rather than silently bundling a consumer migration.
• No unrelated dependency/lockfile, runtime-policy or formatting churn.

Run the relevant existing checks, including:

python -m nox -s tests lint
npm --prefix .\typescript test
npm --prefix .\typescript run build
npm --prefix .\typescript run lint

Also validate remaining workflow YAML/references and perform an isolated local Python install/bundle smoke check if metadata changes. If source-revision metadata is introduced, exercise the installed artifact without relying on the source checkout's .git directory.

Non-goals

• No change to tool versions, dependency constraints, Python/Node/VS Code support versions, or minimum-tool checks. Those are unrelated to this repository's own release-version bookkeeping.
• No npm/PyPI publishing migration, new release service, mandatory version generator, executor/settings refactor, or directory reorganization.
• No rewriting/deleting historical tags, releases or changelog records.
• No S2 test changes or S1 CI-test changes; those proceed independently.
• No full S4 cross-consumer provenance/canary implementation in this cleanup.