pytest and semantic versioning compliance

[rite2hhh]

pytest Changelog states the following

Versions follow Semantic Versioning (<major>.<minor>.<patch>).

Backward incompatible (breaking) changes will only be introduced in major versions with advance notice in the Deprecations section of releases.

However, I see that there were "Breaking changes" in v7.1.0; were these breaking changes actually made in v7.0.0 and only documented in v7.1.0?

If not, it doesn't look like pytest followed semantic versioning in this specific instance. In v7.1.0 case py36 was dropped, given that py37 is going to be EOL soon (May/June 2023), should users expect proper semantic version compliance and a MAJOR bump when a support for a Python version is dropped by pytest in the future? (I understand that pytest may not drop support for py37 immediately)

We're using pytests and wanted to understand if pytest>=7.0.0,<8.0.0 in our dependencies would be sufficient.
Any help would be appreciated.

EDIT: Read through the issue #9437 later, is it safe to assume that dropping support for py36 in a MINOR version was an exception not the rule? (comment that shares some insight)

Thanks!

[RonnyPfannschmidt]

unless you have a process in place that auto unpins/updates regular, its recommended to only pin the minimal version

[rite2hhh]

@RonnyPfannschmidt
Thanks for your prompt response!

Following guidelines in PEP 440 for semantic versioning compatibility in Python projects, and going through semver.org clause 1-8 (as stated in PEP), it seems that pinning only the minimum version for pytest will expose our projects to install v8.0.0.

When v8.0.0 is released (hypothetically speaking) with breaking changes (following the semver convention), it will potentially break our code. AFAIK version dependencies would resolve at package install time (via pip), in which case, it actually makes sense to pin the maximum version (I think).

Do I understand that correctly?

[rite2hhh]

Talking specifically about dropping support for an older Python version in MINOR releases - it's safe because package installers like pip would install the correct version of pytest for a given Python version, my concern is more around pytest making breaking changes for other public interfaces. I used the py versions simply as a example.

[RonnyPfannschmidt]

a lot of the breaking changes in the last few years where not breaking changes for consumers of pytest/its plugins
i consider it more o net-neative to pin harder than necessary

[rite2hhh]

semver suggests calling a change as "Breaking" only if it affects the public API https://semver.org/spec/v2.0.0.html#spec-item-8, but I get where you are getting at!

I agree to not pin the versions to a restrictive range! I'll add version ranges accordingly.

Thank you!