when to fix cross-version bugs?
I recently committed a fix for unicodeobject.c so that the %d, %i, and %u format specifiers always output values (otherwise, in subclasses, the str() was used instead). Should this be fixed in 3.3 as well? What guidelines determine when a bug is fixed in previous versions? -- ~Ethan~
On Fri, Sep 6, 2013 at 9:51 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
I recently committed a fix for unicodeobject.c so that the %d, %i, and %u format specifiers always output values (otherwise, in subclasses, the str() was used instead).
Should this be fixed in 3.3 as well?
What guidelines determine when a bug is fixed in previous versions?
If it's a bug in that version and the version is accepting bug fixes, i.e., not in security mode, go for it. This includes crossing the 2/3 boundary if applicable.
On Fri, 06 Sep 2013 07:51:06 -0700, Ethan Furman <ethan@stoneleaf.us> wrote:
I recently committed a fix for unicodeobject.c so that the %d, %i, and %u format specifiers always output values (otherwise, in subclasses, the str() was used instead).
Should this be fixed in 3.3 as well?
What guidelines determine when a bug is fixed in previous versions?
The basic guideline is: we try very hard not to break currently working code in a maintenance release. Making that decision very much depends on the details of each individual case. I'd say this one is borderline...it would probably be OK to backport it, since programs depending on the str of number subclasses (that is what we are talking about here, right? Even though you say the fix is in unicodeobject.c...) are likely to be rare, or already have a workaround that won't get broken by the change, but by the same token it probably doesn't have much positive impact if it does get backported, so is it worth the (small) chance of breaking someone's code? --David
On 09/06/2013 07:51 AM, Ethan Furman wrote:
What guidelines determine when a bug is fixed in previous versions?
On 09/06/2013 08:29 AM, Brian Curtin wrote:
If it's a bug in that version and the version is accepting bug fixes, i.e., not in security mode, go for it. This includes crossing the 2/3 boundary if applicable.
On 09/06/2013 08:31 AM, R. David Murray wrote:
The basic guideline is: we try very hard not to break currently working code in a maintenance release. Making that decision very much depends on the details of each individual case.
[so] it probably doesn't have much positive impact if it does get backported, so is it worth the (small) chance of breaking someone's code?
And they say never go to the elves for advice! ;) -- ~Ethan~
On 7 Sep 2013 02:43, "Ethan Furman" <ethan@stoneleaf.us> wrote:
On 09/06/2013 07:51 AM, Ethan Furman wrote:
What guidelines determine when a bug is fixed in previous versions?
On 09/06/2013 08:29 AM, Brian Curtin wrote:
If it's a bug in that version and the version is accepting bug fixes, i.e., not in security mode, go for it. This includes crossing the 2/3 boundary if applicable.
On 09/06/2013 08:31 AM, R. David Murray wrote:
The basic guideline is: we try very hard not to break currently working code in a maintenance release. Making that decision very much depends on the details of each individual case.
[so] it probably doesn't have much positive impact if it does get
backported, so is it worth the (small) chance of breaking someone's code?
And they say never go to the elves for advice! ;)
Fixes that risk breaking current doctests are rarely worth backporting, so in this case, I'd say only fixing it in 3.4 is the better option. Definitely the kind of borderline case worth asking about, though :) Cheers, Nick.
-- ~Ethan~ _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
participants (4)
-
Brian Curtin -
Ethan Furman -
Nick Coghlan -
R. David Murray