Compatibility fixes and backports ​

A backport applies a fix to an earlier version. Before proposing one, identify the observable problem, the versions actually tested and the smallest regression case that demonstrates the difference. A successful check on the current executable does not establish behavior on an earlier one.

Record a version-specific baseline ​

Keep the executable identity, interface, configuration and exact query with each result. Use disposable data for tests that write or change a schema. Separate the original failure, the intended fix and any unrelated behavior differences.

If a fix changes an adapter, verify its request and result handling with every server version the adapter claims to support. Test both successful responses and the error path that originally failed. Do not add automatic retries for a write without accounting for an uncertain outcome.

Keep the change narrow ​

Include only the fix, its regression coverage and any documentation needed to explain changed behavior. A proposed backport is not evidence that an earlier release will receive it; availability must be confirmed independently.

Use regression test guidance for deterministic cases and integration documentation to state tested versions and limitations without promising an unverified compatibility range.