Don't drop support for minor versions of MkDocs in patch versions of mkdocs-material

[ilyagr]

This is a minor criticism, but I was surprised that the patch version 9.5.22 of mkdocs-material dropped support for the 1.5.* versions of MkDocs and requires me to upgrade to MkDocs 1.6. I would prefer if bugfixes to mkdocs-material did not force such upgrades. You could put the bugfixes into 9.5.22 and then bump the dependency version in 9.6.0, whenever that's ready.

I did appreciate that recent versions of mkdocs-material supported MkDocs 1.6, that seems fine and welcome to me. (Update: I'm not sure if this was intentional, I can't find traces of the period where both 1.5 and 1.6 were supported in this repo. I may have run into a poetry bug or something? In any case, supporting newer versions is nice.)

That said, I'm not sure how much maintenance burden it would be to more closely track dependency version requirements for this project, so if it has to be this way, I can live with it. :) As ever, thanks for making this project.

[squidfunk]

Thanks for asking. I agree that it is debatable whether we should've done a patch or minor version bump when upgrading to the latest MkDocs. However, since we limited the version range of Material for MkDocs to <1.6, bumped it to >=1.6 in 9.5.22, and everything went without any interruption, I considered it safe to release this as a patch release. One could argue that since we limited the version range (for safety, since 1.6 was a big release, as MkDocs hasn't seen a new release for 7 months, and many LOC changed), and Insiders mandates that we upgraded to 1.6, we wanted to reflect this in the community edition as well. Yes, it's not optimal, but we have to make trade-offs with the sponsorware approach that we're following.

There has been quite a heavy discussion around how to do version management in Python in general and for this project in particular in #7076. I understand that everybody has their opinion here, but I kindly ask to respect our decisions on how we view semver, i.e., which parts of this software we consider to be part of the public API.