Breaking changes introduced in version 3.1.0

[adamgregory]

Breaking changes were introduced in Jinja2 3.1.0 which drops support for Python 3.6 and removes code previously deprecated in 3.0.0
https://jinja.palletsprojects.com/en/3.1.x/changes/#version-3-1-0

Despite the deprecation warnings introduced for this functionality in version 3.0.0, making a backwards incompatible change is always a breaking change and should be a major version increase. The Semver documentation has specific guidance on managing deprecated functionality.

I've included the relevant sections below with emphasis added by me:

https://semver.org/#how-should-i-handle-deprecating-functionality

When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.

https://semver.org/#spec-item-8

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.

Hopefully you choose to revise your versioning strategy for future deprecations and breaking changes to align more closely with the semver recommendations.

[davidism]

Please read https://hynek.me/articles/semver-will-not-save-you/, then use a tool like pip-tools to pin your dependencies and control when you get updates. Be sure to run your tests with deprecation warnings treated as errors so that you get notified of these types of changes early.