Sujet : compatibility
-
Protocol Buffers: field numbers, unknown fields and the rules for evolving a message
In Protocol Buffers the field number, not the name, identifies a field on the wire, so numbers must never change or be reused; adding fields is wire-safe, removing them is safe only if the number is never reused (a reserved statement enforces that), old readers keep unknown fields, and widening int32 to int64 is only conditionally safe. ProtoJSON has its own, different rules.
-
Diffing the OpenAPI document in CI catches breaking changes that code review misses
Hypothesis: a CI step that compares the OpenAPI document of each change against the released one with a breaking-change classifier such as oasdiff flags removed fields, narrowed types and new required parameters that human review of the code diff misses, so fewer unintended breaking changes reach a release.
-
Deprecating a function in a library: warn, document the replacement, remove on schedule
A library deprecation has four parts: a replacement that exists first, a runtime warning plus a documentation note naming the version and the replacement, a changelog entry, and a removal release fixed in advance by policy. PEP 387 requires a deprecation period of at least two years under Python's annual cadence and describes a documentation-only soft deprecation; Django removes shims no earlier than two feature releases after the warning.
-
Schema evolution with Avro and Parquet: reader and writer schemas, merged files and compatibility modes
Avro resolves a writer's schema against a reader's schema field by field, filling missing fields from reader defaults and ignoring unknown ones; Parquet files with different but compatible schemas can be merged by the reading engine at a cost; a schema registry enforces backward, forward or full compatibility. Adding optional fields with defaults is the safe move, renaming and type changes are not.
-
Deprecating an API endpoint with Deprecation and Sunset headers
Announce end-of-life in-band: the Deprecation header (RFC 9745) marks a resource as deprecated, the Sunset header (RFC 8594) states when it will stop working, and a Link to documentation explains the replacement; pair them with logging of remaining callers.
-
Supporting several release lines: which fixes go where
A support policy is a table of release lines with a status each (feature, bugfix, security-only, end of life) and a rule for which fix classes are backported to which lines. Python maintains a series with bugfix releases for two years and security-only releases for three more; Django backports critical fixes to the last feature release and security and data-loss fixes to the last two plus long-term-support lines; Rust supports only the most recent stable. A small project should publish the table and default to the narrowest promise it can keep.
-
Match claims to the version they cover
Represent version scope explicitly and refuse to apply a current-documentation claim to an unknown or incompatible installation.
Lisible par machine : JSON