Setuptools: Governance and Change Management Review After Breaking Change

The recent PR #4870, authored by @abravalheri and approved by @jaraco, introduced a breaking change that immediately and broadly disrupted the Python ecosystem by disallowing deprecated dash-separated and uppercase options in setup.cfg. This was merged despite clear acknowledgment that it would break downstream projects:

"if we are feeling brave. But it can break packages that have not addressed the warning."
— @abravalheri

"I'm inclined to say we should do it, even though it will cause some disruption."
— @jaraco

This change effectively broke builds across the ecosystem with no grace period, runtime fallback, or migration tooling—blocking unrelated emergency patches and releases in critical production systems. The follow-up PR #4909 that removed requests from integration tests—because this change broke internal usage—further illustrates how unprepared the project itself was for the consequences of this decision.

Bug #4910 showed just how widespread the issue was.
After widespread backlash, the change was reluctantly reverted in #4911, but when asked if an opt-out would be provided for a future reintroduction, the author responded:

“The option is to pin setuptools via the PIP_CONSTRAINT environment variable... All things considered this is likely a symptom of something bigger, more problematic, and the package you depend upon has been on borrowed time for a while... Organise among other users contributions (or even a fork) for maintenance. Fund the original developers for maintenance. Find a suitable replacement.”
— @abravalheri

This dismissive response shifts responsibility entirely to users and downstream projects without acknowledging the maintainers’ own role in ecosystem stability. It shows a fundamental lack of empathy for maintainers and users who depend on stability and predictable deprecation cycles.

This raises serious questions about:

• Change management and deprecation enforcement policy: Why was a breaking change merged without community consensus or a proper deprecation window?
• Contributor and reviewer accountability: How are high-impact decisions vetted, especially those with acknowledged ecosystem-wide fallout?
• Branch protection and CI governance: How did this change pass review without ecosystem impact validation or internal test failures acting as a safeguard?

We urgently request the following:

• A postmortem detailing what went wrong and how this will be prevented in the future.
• Clear documentation of your deprecation and backwards-compatibility policy.
• Transparency around contributor/reviewer permissions and decision-making authority.
• A published governance or escalation model for controversial or high-impact changes.

The Python ecosystem relies heavily on setuptools, and changes of this magnitude cannot be driven by personal opinion or experimentation—especially when knowingly disruptive.

This incident has eroded trust. Rebuilding that trust will require serious introspection and reform.