Plea for release candidates / announcement to distutils-sig

Sorry to be demanding, but this is a humble request that you add a release candidate phase to the release process.

Like others, most of my packaging builds started failing this morning with #1042 .

Of course, you’re in the unenviable position of being at the bottom of many many stacks, and it’s really hard to avoid these kind of problems. But - it would really help if you would consider making a release candidate and putting it up on pypi. The ideal would be if you could announce somewhere like distutils-sig, so we packagers know to check the release candidate somewhere with pip install --pre setuptools. For example, I am happy to do that by default on the many packaging repos that I have, so that I get the failures immediately, and before they go live by default across the ecosystem - I am sure others are happy to do that too.

That would really help make sure that people don’t get unexpected breakage. Pretty please.

[jaraco]

Thanks for the suggestion. At first blush, it sounds like an excellent idea.

In the past, I have made pre-releases available (example), especially for backward-incompatible releases that were expected to cause disruption (and commensurate with the amount of disruption expected). In practice, I find that even if I cut the release and tweet about it and lead up to it with discussion and invitations to test, if issues are going to emerge, they will emerge after the release, and usually only in a small percentage of total uses.

So I’ve chosen instead to create minimally-invasive, rapid releases such that if issues are reported, they can be readily identified and corrected or rolled back, depending on the severity of the failure and the difficulty of corrective action. Ideally, the unit-test suite will capture all use cases, such that a release is only cut when tests pass.

This approach failed us last night when the release went out late and I managed to fall asleep before noticing any issue.

I loathe to create more manual steps that are unlikely to add significant value but guaranteed to add delays to releases.

I’d prefer to focus on how a broken build was able to bypass the existing safeguards and bolster those safeguards (test suite).

If in light of this, you still think that release-candidates are worth the trouble, we probably need more volunteers on the projects to do that additional work.

[matthew-brett]

Thanks for considering.

I guess that will mean that the easy_install etc installs get what we get now, and other install methods will get a better tested version.