On Sun, 07 Apr 2013 11:48:28 -0400, "R. David Murray" <rdmur...@bitdance.com> wrote: > (much more if the fix doesn't apply cleanly), and I find myself more and > more likely to say "well, it's been that way in Python2 for a long while, > fixing it there is more likely to break things than it is to improve > things, so let's not backport". Or, as gps said, just leaving the issue
Having sent this, I noticed that it is actually a significant point that no one else has raised out, and is worth emphasising. When we fix bugs, there is always a backward compatibility estimation that goes into the fix, and whether to even make the fix in the bug fix release: what are the chances that fixing this bug will break currently working code, versus the chances that currently broken code will start working correctly? If the chance of breakage outweighs the good done, we don't apply the fix to the maintenance release. The longer that a maintenance release is in the field, the higher the probability that fixing a bug will break existing working code. So even *without* a set maintenance end date, the number of bug fixes *should* decline over time. Five years is a long time. By that point, even regardless of any maintenance commitment concerns, it is probably best to stop fixing anything except security bugs *anyway*, as a service to the user community :) --David _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
