Major version change does not imply breaking change in semantic versioning #1223

The following bit taken out of the "install_requires vs requirements files" article is incorrect in my opinion:

It may also be known that project A follows semantic versioning, and that v2 of ‘A’ will indicate a break in compatibility, so it makes sense to not allow v2

As far as I know, semantic versioning (v2.0 at the time if this writing) does not specify that a "breaking change" is a condition necessary for incrementing the major version number. It is perfectly possible to increment the major version number without making any breaking change. It seems to be a rather widespread misunderstanding. This leads to a lot of libraries placing unnecessary upper bounds on their dependencies, which seems to break quite a lot of things in the Python packaging ecosystem nowadays.

I believe the phrasing should be corrected. There is not point in trying to predict the future. Upper bounds should be set once it is actually known that there is a breaking change, not before the breaking change happens.

I guess the following should section be fixed as well:

• https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#semantic-versioning-preferred

Related:

• https://iscinumpy.dev/post/bound-version-constraints/