Tianyi Cui
0112eaf3a8
The integrated V3-to-V4 records contain the header increase that authorizes their breaking changes. Leaving those terminal records editable would let a later change reuse that already accepted 3-to-4 increase, so version 4 would not establish a stable compatibility baseline for persisted user data. Capture the accepted root classifications and semantic record digests in a separate finalization checkpoint. Validate that checkpoint before rendering or writing acknowledgement artifacts, and preserve its accepted records even after the current writer advances. Keep publication evidence independent: the verified released version remains 3 until a release establishes otherwise. Compare future writer-4 schemas with the accepted baseline using the existing compatibility classifier. Compatible additions remain permitted through new same-version acknowledgement records. Breaking changes require a higher writer and their own header transition; comments, aliases and source-location changes do not alter the accepted semantics. Later unaccepted compatible records retain the existing update workflow. Document the distinction between finalization, publication and compatible evolution, with regression coverage for locked records, incomplete or inconsistent checkpoints, additive changes and future-version transitions.
7 lines
434 B
YAML
7 lines
434 B
YAML
# Bilingual-pair consistency record (docs/i18n/README.md): the git blob hash of each
|
|
# side as of the last confirmed-consistent state. Both languages carry equal authority;
|
|
# after editing either side, bring the other along and re-record with:
|
|
# pnpm run verify-translation-pairing --write docs/persistence-changes/README.md
|
|
README.md: 3fd95e48548fdb9c1d04330c2925096d072850d1
|
|
README.zh.md: f4ab3b3d22b1aa2f7f5923e84fd4effc339874db
|