From ec1fef8913a32f0ef8f3c1b71c154cace318c15d Mon Sep 17 00:00:00 2001 From: Emmanuel Prunet Date: Fri, 2 Oct 2026 09:01:08 +0200 Subject: [PATCH] governance: during 0.x a breaking change needs no rfc: issue and no comment window; the RFC comes back at the v1.0 freeze, or earlier the day a second implementation is listed (closes #8) The reference implementation is today the only producer and consumer, so a comment window protects no one. The pull request still states the SPEC.md diff and the migration impact, and CHANGELOG.md records the change as breaking. Co-Authored-By: Claude Opus 5.5 --- CHANGELOG.md | 7 +++++++ CONTRIBUTING.md | 6 ++++-- GOVERNANCE.md | 29 ++++++++++++++++++++++++++--- 3 files changed, 37 insertions(+), 5 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index a1cb10a..b9d8905 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -60,6 +60,13 @@ definition under *Changed***: it is a breaking change of its own, proposed and a in pull request [#14](https://github.com/CodeRoasted/metalog-spec/pull/14) under its own 14-day comment window. +**Process: RFC #8 is closed, and breaking changes need no RFC during 0.x.** +[`GOVERNANCE.md`](GOVERNANCE.md) §2 now lets the editor merge a breaking change in the +0.x line without an `rfc:` issue or a comment window, while the reference +implementation is the only producer and consumer. The RFC comes back at the v1.0 +freeze, or earlier the day a second implementation is listed. P1, P3 and P4 stay +proposed; any of them that is taken lands as an editor change recorded here. + ### Changed - **§13.2 now quantifies over a VERDICT, not over field presence.** The old clause diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b5176cf..f097719 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -68,8 +68,10 @@ merges these on sight. validates the example file against the shipped schema. Run both locally first — see [`conformance/README.md`](conformance/README.md). 3. Editor (or a reviewer) reviews. Additive changes get merged - after one approval; breaking changes follow the RFC process in - [`GOVERNANCE.md`](GOVERNANCE.md). + after one approval; breaking changes follow [`GOVERNANCE.md`](GOVERNANCE.md) + §2 — merged by the editor during 0.x, and through an `rfc:` issue and + its comment window from the v1.0 freeze (or once a second + implementation is listed). 4. Merged changes update `CHANGELOG.md`. --- diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 4ef4658..f5d1034 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -29,9 +29,32 @@ that means for each change type; a reader should not have to infer it. |---|---|---|---| | **Editorial** | Typo, wording clarification, additional example | Editor merges. | Editor merges. | | **Additive** | New optional field, new enum value, new extension prefix | Editor merges. MINOR bump. **The 1-reviewer approval below activates once a reviewer roster exists.** | Editor merges after 1 reviewer approval. MINOR bump. | -| **Breaking** | Remove a field, change a field type, change `template_id` algorithm | Editor merges after RFC issue + 14-day comment window. MAJOR bump (or MINOR during 0.x). | Requires RFC + 30-day comment window + at least 2 reviewer approvals. MAJOR bump. | +| **Breaking** | Remove a field, change a field type, change `template_id` algorithm | Editor merges. MINOR bump. **No RFC issue and no comment window** — see *Breaking changes during 0.x* below. | Requires RFC + 30-day comment window + at least 2 reviewer approvals. MAJOR bump. | | **Profile** | "Streaming MetaLog", "Edge MetaLog" subset profiles | Same as breaking. | Same as breaking. | +### Breaking changes during 0.x + +While the spec is in its `0.x` draft line, a breaking change needs **no `rfc:` issue +and no comment window**: the editor merges it, with a MINOR bump (§6: during 0.x a +MINOR may break). A comment window exists to protect implementers a change would +break, and today the reference implementation is the only producer and consumer of +MetaLog documents — so a window protects no one, and only holds back a correction +the editor has already decided. + +**What replaces the window.** The pull request states the change as a diff against +`SPEC.md` and gives its migration impact (items 2 and 4 of an RFC issue, below), and +`CHANGELOG.md` records it as breaking in the same pull request. The record is kept +whole; only the wait is waived. + +**The RFC comes back at freeze, and that is not discretionary.** From the moment +v1.0 is frozen under [ADR 0001](adr/0001-v1-freeze-policy.md), every breaking change +and every profile requires an `rfc:` issue and the *Process at 1.0+* column above. +It comes back **earlier, while still 0.x, the day a second implementation is listed** +in [`README.md`](README.md)'s implementation table — ADR 0001's first freeze +condition requires one, so this always happens before the freeze. From that day a +breaking change can break someone other than the editor, and every breaking change +not yet merged takes an `rfc:` issue and a 14-day comment window. + An **RFC issue** is a GitHub issue tagged `rfc:` containing: 1. The problem being solved, with at least one concrete example. @@ -73,8 +96,8 @@ generic. 1. Comment on the relevant PR or issue. 2. If unresolved, open an `rfc:` issue with the alternative proposal. -3. If still unresolved after the comment window, the editor decides - and documents the rationale in the merged PR. +3. If still unresolved — after the comment window, where §2 requires + one — the editor decides and documents the rationale in the merged PR. There is no appeal process during 0.x. After 1.0, a steering committee structure will be defined here if the implementer base