Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
6 changes: 4 additions & 2 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -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`.

---
Expand Down
29 changes: 26 additions & 3 deletions GOVERNANCE.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand Down
Loading