On 2020-02-04 12:10, Brett Cannon wrote:
Please be careful making that claim. Over my 16 years of helping manage this project I can tell you that claim is not universally true no matter how small and simple you think something is.
The answer to that concern is to not break compatibility in the first place, and/or revert it when the mistake is discovered. It happens. As mentioned, significant breaks are now discouraged. The code is already written, so I'd argue keeping it deprecated potentially a few years extra in a regular process is not an undue burden.
Python predates semver. Assume every feature/minor release potentially has a breaking change and we have (hopefully) been raising warnings to the user for the past two years about the breaking change coming.
Hmm, was thinking about MS-DOS when I wrote that. Still, I don't think this a good system having breaking changes in the minor version number. It's not traditional and it's not newfangled either, it's relatively unique. On that note, just noticed that Wikipedia has its own section for Python under the "Software Versioning" article: The PSF has published PEP 440 -- Version Identification and Dependency Specification,[16] outlining their own flexible (complicated) scheme, that defines an epoch segment, a release segment, pre-release and post-release segments and a development release segment. https://en.wikipedia.org/wiki/Software_versioning#Python The main argument here seems to be it this uncommon versioning scheme saves core developer time, (unsaid) at the expense of dev or end-user time. As there are probably a million end-users per Python contributor, I argue this is not a good tradeoff to make. -Mike