On 2020-02-04 14:40, Paul Moore wrote:
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.
No, I chose the wrong phrasing there. Have been arguing for deprecations to occur on schedule but removals to occur later. By "not break compatibility…" I meant not to break it in a large, destructive manner. Small ones, sure.
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.
This happens already and won't go away. I'm arguing that a *very* predictable release process helps and doesn't hurt in this department, resulting in fewer questions. Instead of every release is a unique snowflake to be considered. Still have questions? Go to FAQ #42.
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
It matters, when say Ubuntu drops X.4 when X.6 comes out and X.6 isn't backwards compatible. You get forced to update or find one of the various workarounds. I argue this should happen less frequently at predictable times.
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.
Sorry, didn't mean that part as an attack, rather an illustration of the tradeoff being made. Now if PSF needs help to build a more predictable release process, well then, by all means ask. But that can't happen until the decision is made to do it.