Define and document clearly what constitutes a breaking change
Before we can consider goal 3 complete, we must document what it means to make a breaking change so that we do not accidentally make breaking changes in the future.
For example:
- Changing how the CLI works such that existing invocations would fail is a breaking change
- Changing how the Rust bindings operate such that developers would have to update both subplot-build and subplotlib in lockstep
However, for the purpose of step libraries:
- Adding new patently clear steps to our step libraries is not a breaking change
- Altering the behaviour of a step in our step libraries such that it no longer behaves the same is a breaking change
We justify 1 above by stating that users of subplot who "fill gaps" in our libraries must be careful to ensure that their step text would be unlikely to conflict, or must be prepared to update their bindings after an upgrade of subplot.
Further thoughts to be included when this is documented into DECISIONS.md
or else the manual somewhere