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.
-Mike
_______________________________________________
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/KJPMNIXB3GX6GEOHTXA324DFJBSJFKHO/
Code of Conduct: http://python.org/psf/codeofconduct/
