say we claim support for >=1, <3
- 1.0 is the first supported version.
- if this isn't tested, features from later versions may be depended on that break compatibility with this version.
- 1.x adds to it.
- test the latest version available to detect new features that collide (e.g. variables named
async
are fine in python 3.6 butasync
becomes a keyword in python 3.7).- only the latest version needs to be tested because features cannot be removed without a major version bump.
- if something breaks, either
- a new feature collided with existing code
- upstream did not follow semver and broke compatibility
- existing code uses upstream code that is not part of the public API
- test the latest version available to detect new features that collide (e.g. variables named
- 2.0 can break compatibility, so treat it like 1.0.
- 2.x should be tested for the same reason as 1.x.
Overall, we test 4 versions (~=1.0.0
, ~=1.0
, ~=2.0.0
, and ~=2.0
) no matter how many 1.x
or 2.x
releases there are.