Versioning and compatibility¶
pyxaf follows Semantic Versioning 2.0. Every release is listed in the changelog.
Before 1.0¶
Until version 1.0 the API can still change. pyxaf keeps changes predictable:
| Release | May contain |
|---|---|
patch (0.y.Z) |
bug fixes and documentation only |
minor (0.Y.0) |
new features, and breaking changes to the public API, each listed in the changelog with a migration note |
From 1.0 on, breaking changes need a new major version.
What the public API is¶
These are covered by the compatibility promise:
- the names exported by the
pyxafpackage (pyxaf.__all__), the public modulespyxaf.rgsandpyxaf.tables, and everything documented in the API reference; - the finding codes: a code is never renumbered, reused or given a new meaning. Changing a code's default severity is a listed change;
- the table schemas: column names and types. New columns may be added;
- the command line: commands, options, exit codes and the JSON report layout, which is versioned
by
schema_version.
These are not covered and may change in any release: modules and names starting with an
underscore (pyxaf._xml, pyxaf.catalogue._generated_xaf40, …), the exact wording of finding
messages and log output, and the bundled schema files.
A newer pyxaf may report findings that an older one did not, because it checks more. Do not treat "no new findings" as part of the API; pin the version when you need identical reports.
Deprecations¶
A feature that is going away first raises a DeprecationWarning that names the replacement and
the version that removes it. It is removed no earlier than the next minor release, and the
changelog lists it under Deprecated and later under Removed. To see deprecation warnings
in your own code, run Python with -W default::DeprecationWarning or let pytest show them.
Supported Python versions¶
pyxaf supports CPython 3.11 and newer and is tested on Linux, macOS and Windows. Support for a Python version ends in a minor release after that version reaches its upstream end of life.