98 lines
2.9 KiB
Markdown
98 lines
2.9 KiB
Markdown
# PBS Compatibility Workshop 1
|
|
|
|
Status: Active
|
|
|
|
## Purpose
|
|
|
|
Run the first focused discussion for `17. Compatibility and Evolution Policy.md` on the top-level policy model:
|
|
|
|
- which compatibility domains PBS recognizes,
|
|
- and what strength of promise applies to each.
|
|
|
|
## Why This Slice First
|
|
|
|
This slice should come first because every deprecation, migration, and matrix policy depends on a clean definition of domains and promise levels.
|
|
|
|
## Proposed Meeting Order
|
|
|
|
1. Reconfirm already-settled governance and versioning inputs.
|
|
2. Close the compatibility domains.
|
|
3. Close the promise level for each domain.
|
|
4. Close behavioral versus binary compatibility terminology.
|
|
5. Record migration and matrix issues for later workshops.
|
|
|
|
## Decisions To Produce
|
|
|
|
1. The compatibility domains PBS speaks about normatively.
|
|
2. The promise level for each domain.
|
|
3. The behavioral versus binary compatibility split.
|
|
4. The relationship between claim level and compatibility promise.
|
|
|
|
## Candidate Decisions
|
|
|
|
### 1. Recognize Separate Domains
|
|
|
|
Candidate direction:
|
|
|
|
- PBS should distinguish at least:
|
|
source compatibility,
|
|
stdlib compatibility,
|
|
cartridge/runtime compatibility,
|
|
artifact compatibility,
|
|
and conformance-claim compatibility.
|
|
|
|
Rationale:
|
|
|
|
- Different breakages affect different users and toolchains.
|
|
|
|
### 2. Promise Strength Differs By Domain
|
|
|
|
Candidate direction:
|
|
|
|
- source and published-cartridge behavior get the strongest promise,
|
|
- stdlib and artifact domains may have tighter line-based conditions,
|
|
- partial conformance claims get narrower promises than full ones.
|
|
|
|
Rationale:
|
|
|
|
- This avoids one vague compatibility slogan that means too many things.
|
|
|
|
### 3. Separate Behavioral From Binary Compatibility
|
|
|
|
Candidate direction:
|
|
|
|
- source-level and runtime-observable behavior compatibility is not the same as artifact binary compatibility,
|
|
- and the policy should state both explicitly.
|
|
|
|
Rationale:
|
|
|
|
- This prevents PBX policy from silently driving all evolution policy.
|
|
|
|
## Questions To Resolve In The Room
|
|
|
|
1. What are the minimum compatibility domains that PBS must name explicitly?
|
|
2. Which domains deserve the strongest guarantees?
|
|
3. Is cartridge compatibility mainly behavioral, binary, or both?
|
|
4. How does staged conformance affect compatibility promises?
|
|
5. Does stdlib compatibility belong as its own domain or inside source compatibility?
|
|
|
|
## Expected Outputs
|
|
|
|
1. a decision record for compatibility domains,
|
|
2. a promise-level matrix draft,
|
|
3. and terminology targets for `17`.
|
|
|
|
## Explicit Deferrals For Workshop 2
|
|
|
|
- deprecation windows,
|
|
- migration-tooling duties,
|
|
- and artifact-line change policy.
|
|
|
|
## Inputs
|
|
|
|
- `docs/pbs/specs/2. Governance and Versioning.md`
|
|
- `docs/pbs/specs/13. Conformance Test Specification.md`
|
|
- `docs/pbs/specs/17. Compatibility and Evolution Policy.md`
|
|
- `docs/pbs/decisions/Conformance Claim Levels Decision.md`
|
|
- `docs/pbs/agendas/17. Compatibility and Evolution Policy Agenda.md`
|