108 lines
3.0 KiB
Markdown
108 lines
3.0 KiB
Markdown
# PBS Compatibility Workshop 3
|
|
|
|
Status: Decision recorded
|
|
|
|
## Purpose
|
|
|
|
Run the third focused discussion for `17. Compatibility and Evolution Policy.md` on support claims over time:
|
|
|
|
- compatibility matrices,
|
|
- supported combinations,
|
|
- published claims,
|
|
- and how those claims age or retire.
|
|
|
|
## Resolution Snapshot
|
|
|
|
This workshop direction is now recorded in:
|
|
|
|
- `docs/pbs/decisions/Compatibility Matrix and Published Claims Decision.md`
|
|
|
|
Integrated spec follow-up belongs to:
|
|
|
|
- `docs/pbs/specs/13. Conformance Test Specification.md`
|
|
- `docs/pbs/specs/17. Compatibility and Evolution Policy.md`
|
|
|
|
## Why This Slice Third
|
|
|
|
This slice follows domain and lifecycle policy because matrix policy is where those choices become operational.
|
|
|
|
## Proposed Meeting Order
|
|
|
|
1. Reconfirm domain and lifecycle decisions from Workshops 1 and 2.
|
|
2. Close the shape of the compatibility matrix.
|
|
3. Close what counts as a published support claim.
|
|
4. Close how claims retire or narrow over time.
|
|
5. Record artifact-specific leftovers for Workshop 4.
|
|
|
|
## Decisions To Produce
|
|
|
|
1. The compatibility-matrix dimensions PBS must publish.
|
|
2. The policy for published support claims.
|
|
3. The relationship between claims, conformance, and regression.
|
|
4. The retirement policy for supported combinations.
|
|
|
|
## Candidate Decisions
|
|
|
|
### 1. Publish A Matrix Across The Major Compatibility Domains
|
|
|
|
Candidate direction:
|
|
|
|
- the matrix should cover at least:
|
|
language line,
|
|
stdlib line,
|
|
runtime line,
|
|
and conformance claim level.
|
|
|
|
Rationale:
|
|
|
|
- These are the main axes users will rely on.
|
|
|
|
### 2. Published Claims Must Be Backed By Conformance Or Regression Evidence
|
|
|
|
Candidate direction:
|
|
|
|
- support claims are not just prose;
|
|
- they must correspond to maintained test evidence where support is promised.
|
|
|
|
Rationale:
|
|
|
|
- This aligns policy with `13`.
|
|
|
|
### 3. Unsupported Combinations Must Be Explicit
|
|
|
|
Candidate direction:
|
|
|
|
- the matrix must allow explicit “unsupported” states rather than implying silence equals support.
|
|
|
|
Rationale:
|
|
|
|
- This reduces accidental ambiguity.
|
|
|
|
## Questions To Resolve In The Room
|
|
|
|
1. What exact axes belong in the official matrix?
|
|
2. Must every supported combination have conformance evidence?
|
|
3. How should experimental or provisional combinations be labeled?
|
|
4. When support is dropped, how is that reflected in the matrix and docs?
|
|
5. Which parts of this are policy versus test-harness detail?
|
|
|
|
## Expected Outputs
|
|
|
|
1. a decision record for the compatibility-matrix model,
|
|
2. a published-claims policy note,
|
|
3. and alignment tasks for `13`.
|
|
|
|
## Explicit Deferrals For Workshop 4
|
|
|
|
- PBX compatibility,
|
|
- binary-loading policy,
|
|
- and artifact-line changes.
|
|
|
|
## Inputs
|
|
|
|
- `docs/pbs/specs/13. Conformance Test Specification.md`
|
|
- `docs/pbs/specs/17. Compatibility and Evolution Policy.md`
|
|
- `docs/pbs/decisions/Compatibility Matrix and Published Claims Decision.md`
|
|
- `docs/pbs/agendas/17.1. Compatibility Workshop 1 - Compatibility Domains and Promise Levels.md`
|
|
- `docs/pbs/agendas/17.2. Compatibility Workshop 2 - Deprecation, Removal, and Migration Duties.md`
|