On Tue, 4 Feb 2020 at 22:10, Mike Miller <python-...@mgmiller.net> wrote: > > 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.
That sounds to me like an argument for stagnation. We already take backwards compatibility very seriously. If you're suggesting that we don't even have the option of deprecating things, then I'm not sure how you expect the language to evolve. > 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. The point has already been made that "keeping code around but deprecated" isn't the problem, it's bug triage, telling people who report problems with deprecated code that "this is not going to be fixed", educating people who copy/paste old and deprecated code and wonder why they are now getting warnings with it, etc. I think it's probably up to the core devs (who do the work) to judge what is an "undue burden", but if you do want to try to judge it, please take all of those extra tasks into account when reckoning up. > > 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. I have seen many systems that have breaking changes in the minor version, as you describe it. (Java 1.1 to Java 1.4 are a good example - so good that they "rebranded" the minor version as the major version with 1.5!). Restricting compatibility breaks to the major version isn't that important in my experience. IMO, the version number isn't anywhere near as important as the *process* of handling backward compatibility and giving users a good transition path. Knowing what the rules being followed are is the most important thing - and people trying to claim that semver concepts apply to a system that doesn't use it, just because the version number syntax looks like semver, is one of the worst ways to confuse the message IMO. > 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 PEP 440 is not about Python's own version scheme, it's a standard for versioning Python *packages* that are published on PyPI and managed by tools like pip. It's complicated because it has to allow for many different legacy versioning schemes which were in use by existing projects when the PEP was defined. Ideally we would have chosen a simpler scheme, but that would have required breaking many existing projects' version schemes, so we chose not to do that. So it's actually a great demonstration of how not being able to deprecate old usages *adds* complexity and maintenance burden. But it's an irrelevant side issue when talking about the Python language version itself, as PEP 440 doesn't apply to that. > 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. No, it's that conserving the *extremely* limited resource that is freely donated, volunteer core developer time is essential if we want to have a viable core development team at all. If in doing so, we need to have a controlled deprecation process that places some of the burden of keeping up to date on end users who benefit for no cost from the huge amount of donated software and support that makes up what people think of as "Python", then that should be an entirely acceptable trade-off. Paul _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/37K2HWAY5LXLF6W2HKUL5T46JBB4DVWQ/ Code of Conduct: http://python.org/psf/codeofconduct/
