Related to the accelerated release cadence, one of the main pain points of new releases for Extension-developers is the fact that release tooling can be cumbersome and slow to update to add entries for 3.9, 3.10, etc. The need for this is mainly because Extensions must be recompiled to be compatible with the latest ABI. A corollary of the accelerated release cadence is that there could be more consecutive releases that are ABI-compatible, so the only real difference between installations is the path. That can be frustrating. If two Python versions are ABI-compatible, it would be nice if a wheel / installation could be considered fully compatible such that a new wheel/etc. need not be built. Using the ABI version in the path instead of the Python minor version is one possible path to decoupling compatibility from the increasingly rapidly changing version number. For example
Does this seem like it could be feasible?
Conda package maintainers of pure Python packages can feel this pain because they must publish a new build for the new Python when no new release has been made and nothing needs to be done for PyPI (conda’s noarch builds alleviate this for some packages, but certain features, such as platform- or version-dependent dependencies, cannot be used in noarch conda packages). The only difference in these cases for conda packages is the version number in the site-packages path.