Problem
Beyond our builtin backends there are a few third party ones. It is extremely difficult to evolve the backend API without hard-breaking these third party backends.
Issues with the current state:
Proposed solution
We define a backend version. It unambiguously describes the expected functionality of an interface.
- The current is version 1.0
- API changes result in a new backend version.
- Backends must define the version they are written for. All backends that do not explicitly specify a version are considered to be version 1.0.
- A Matplotlib version can decide to accept multiple backend versions, e.g. we could at some point accept v1.0, v2.0 and v3.0 and selectively call appropriate functions.
- We may later decide to drop support for v1.0 in which case we'd reject to load backends of that version.
This should allow to evolve the backend API and third partry backends alongside with grace transition periods so that we maintain maximal compatibility throughout the evolution.
Problem
Beyond our builtin backends there are a few third party ones. It is extremely difficult to evolve the backend API without hard-breaking these third party backends.
Issues with the current state:
draw_path_collection()API #30547 suggests a one-time API break to make changes like Add hatchcolor parameter for Collections #29044 more tractable in the futureProposed solution
We define a backend version. It unambiguously describes the expected functionality of an interface.
This should allow to evolve the backend API and third partry backends alongside with grace transition periods so that we maintain maximal compatibility throughout the evolution.