This software library is meant to evolve rapidly and, as such, does not follow Qiskit's deprecation policy. Nonetheless, we will always try to give users ample time to adjust to changes without breaking code that they have already written.
To avoid dependency issues, exact version specification is encouraged if no upcoming updates are needed (e.g. version pinning).
Following Python's naming conventions as outlined by PEP8, any module, variable, function, or class whose name starts with a leading underscore _ will be considered internal and not part of this library's supported application programming interface (API).
Some capabilities may be pre-released before reaching a stable state. These will not adhere to the deprecation policies in place and will actively warn users of their unstable, pre-release, condition until they are deemed otherwise.
Every other piece of source code conforms the public-facing API of this library and will therefore be subject to the rules outlined in this document.
In order to avoid redundancy with Qiskit and other IBM software products, once a specific capability from this library gets integrated into IBM's stable product stack we will proceed to its deprecation here.
Said deprecation process will last for at least three months, and will not begin until a migration guide explaining users how to transition to the new product feature is produced, approved, and published.
This library follows semantic versioning (i.e. MAJOR.MINOR.PATCH).
In most cases, functionality will not be changed or removed without displaying active warnings for a sufficiently long period of time. During this period, we will keep old interfaces and mark them as deprecated. Deprecations, changes and removals are considered API modifications, and can only occur in minor releases, not patch releases.
We may occasionally introduce breaking changes (i.e. backwards incompatible) in order to bring new functionality to users more rapidly, simplify existing tooling, or facilitate maintenance. These changes will only be included in major releases.
Major version zero (i.e. 0.X.Y) may include breaking changes in minor releases.
Each substantial improvement, breaking change, or deprecation occurring for each release will be documented in CHANGELOG.md.