sphinxcontrib-* builder packages should follow same versioning scheme as Sphinx

[stephenfin]

(I'm filing this here since the issue trackers for the various sphinxcontrib-* builder packages are disabled).

We recently(ish) released new versions of the split-out sphinxcontrib-* builder packages, namely:

• sphinxcontrib.applehelp 1.0.5
• sphinxcontrib.devhelp 1.0.3
• sphinxcontrib.htmlhelp 2.0.2
• sphinxcontrib.serializinghtml 1.1.6
• sphinxcontrib.qthelp 1.0.4

(sphinxcontrib.jsmath should have been on that list but it seems we still don't have permissions to fix that #11559).

These were all patch version bumps, but each version dropped support for Python 3.8. These should really have been at least minor version bumps [*] (e.g. 1.0.4 -> 1.1.0 rather than 1.0.5) since this is a rather large change (it drops support for a feature, in this case a Python version that is still supported upstream for another year).

Where do we define our release process for these sub-packages? Assuming folks agree with my assessment that this should have been more than a patch release, is there an improvement we can make to these docs (or elsewhere) to prevent this happening again?

[*] or, better, major version bumps since we allege to follow semantic versioning. By the same measure though, the recent 7.2.0 release should really have been an 8.0.0 release or we should have held off dropping Python 3.8 support until we were ready. I'm less willing to die on that hill, however.

[woutervh]

Question:
Why are these external packages hard dependencies of Sphinx?
I never use applehelp or devhelp, so why does it need to be installed?