94 lines
3.1 KiB
Markdown
94 lines
3.1 KiB
Markdown
# PBS Compatibility Workshop 4
|
|
|
|
Status: Active
|
|
|
|
## Purpose
|
|
|
|
Run the fourth focused discussion for `17. Compatibility and Evolution Policy.md` on artifact compatibility:
|
|
|
|
- PBX compatibility,
|
|
- runtime-loading compatibility,
|
|
- and how artifact-line changes are versioned and promised.
|
|
|
|
## Why This Slice Last
|
|
|
|
This slice should come last because artifact policy is the most backend-dependent and should be informed by the broader domain and matrix decisions first.
|
|
|
|
## Proposed Meeting Order
|
|
|
|
1. Reconfirm the source, stdlib, cartridge, and matrix policy already chosen.
|
|
2. Decide whether artifact compatibility is an independent policy track.
|
|
3. Decide PBX and runtime-loading promise boundaries.
|
|
4. Decide how artifact-line changes are versioned and communicated.
|
|
5. Record final integration tasks for `17`, `15`, and `19`.
|
|
|
|
## Decisions To Produce
|
|
|
|
1. Whether artifact compatibility is independent from source compatibility.
|
|
2. The promise boundary for PBX and loader compatibility.
|
|
3. The versioning and communication policy for artifact-line changes.
|
|
4. The relationship between artifact policy and published cartridge support.
|
|
|
|
## Candidate Decisions
|
|
|
|
### 1. Artifact Compatibility Is A Distinct Policy Track
|
|
|
|
Candidate direction:
|
|
|
|
- PBX and emitted-artifact compatibility should be named explicitly rather than assumed from source compatibility.
|
|
|
|
Rationale:
|
|
|
|
- Binary and loader compatibility carry different risks and evolution constraints.
|
|
|
|
### 2. Runtime Loading Promise Must Be Stated By Supported Line
|
|
|
|
Candidate direction:
|
|
|
|
- artifact compatibility should be expressed against explicit runtime and artifact lines,
|
|
- not as a timeless blanket guarantee.
|
|
|
|
Rationale:
|
|
|
|
- This keeps the promise honest and testable.
|
|
|
|
### 3. Artifact-Line Breaks Require Explicit Version Signaling
|
|
|
|
Candidate direction:
|
|
|
|
- incompatible artifact changes require an explicit line or major-boundary signal,
|
|
- plus migration or tooling guidance when older published cartridges are affected.
|
|
|
|
Rationale:
|
|
|
|
- This aligns artifact evolution with the broader compatibility policy.
|
|
|
|
## Questions To Resolve In The Room
|
|
|
|
1. How strong should PBX compatibility promises be?
|
|
2. Are published cartridges protected mainly by source compatibility or by explicit artifact-line support?
|
|
3. What counts as an artifact compatibility break?
|
|
4. Must artifact-line changes always align with major language-version changes?
|
|
5. How should loader support boundaries be documented and tested?
|
|
|
|
## Expected Outputs
|
|
|
|
1. a decision record for artifact compatibility policy,
|
|
2. a PBX/runtime promise note,
|
|
3. and final section targets for `17`.
|
|
|
|
## Explicit Deferrals
|
|
|
|
- exact PBX layout details,
|
|
- exact loader algorithms,
|
|
- and binary test harness implementation.
|
|
|
|
## Inputs
|
|
|
|
- `docs/pbs/specs/6.2. Host ABI Binding and Loader Resolution Specification.md`
|
|
- `docs/pbs/specs/13. Conformance Test Specification.md`
|
|
- `docs/pbs/specs/15. Bytecode and PBX Mapping Specification.md`
|
|
- `docs/pbs/specs/17. Compatibility and Evolution Policy.md`
|
|
- `docs/pbs/specs/19. Verification and Safety Checks Specification.md`
|
|
- `docs/pbs/agendas/17.3. Compatibility Workshop 3 - Compatibility Matrices and Published Claims.md`
|