Frequent updates

I would agree lots of small breaking changes tend to be easier to handle than a large one (as long as the effort to fix them is minimal, which is not always the case). I think though this all assume said changes are worth the pain, and maybe in some cases a major break is sometimes better because it forces a reset of how things are though of.

From what I've seen of setuptools issues, because of its long legacy, no matter what setuptools does, any changes setuptools makes to try to modernise will break large numbers of packages (and because wheels as distribution artefacts vs build caches are in many ways a least-common-denominator option, people keep relying on legacy distutils and setuptools features). This then means as soon as a package's packaging config is not kept up-to-date (even though it may need no other changes), issues arise. It also means the long tail of versions break in painful ways.

The obvious solution is to be picky about your dependency tree, and vendor and rewrite as needed, but if we're routing around issues with setuptools, at what point does it make sense to fork it (either freezing the old version, or making a more stable fork) rather than all the other packages?