On a major release, yes, but not on a bugfix release. -FM
On 6/10/08, Brian Fisher <[EMAIL PROTECTED]> wrote: > I would disagree that it's more important that all the code that ran before > runs on the new version without exception than it is to change the new > version so that bad nonfunctioning or error-prone code doesn't silently > fail. > > The way I think of it is, What happens when the code that didn't run before > fails to run with the new error checking? If what happens is the developer > learns that the code is bad and it breaks and messes up locking, and it gets > rewritten in a way that makes sense, than I say it's a good thing, and if > that developer were me I would appreciate it very much that the behavior > changed. > > I do admire and appreciate the devotion to backwards compatibility, I just > think there are cases that are worth changing the behavior, and so far this > seems like a good one to me. > > > On Tue, Jun 10, 2008 at 6:07 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > >> sure. We want to try to not breaking existing code if possible. >> >> Note, that currently Marcus's code seems to work with the existing >> surfarray using code that I've tried. I've tried the >> example/arraydemo.py and one app so far. >> >> Here's a list of surfarray using code if someone wants to test more: >> http://www.google.com/codesearch?q=import+surfarray >> >> cheers, >> >> >> >> On Wed, Jun 11, 2008 at 10:26 AM, Brian Fisher >> <[EMAIL PROTECTED]> wrote: >> > Even bad broken code? >> > >> > On Tue, Jun 10, 2008 at 4:09 PM, René Dudfield <[EMAIL PROTECTED]> wrote: >> >> >> >> Also note that we *need* to retain compatibility with existing code - >> >> at least for pygame 1.8.1. We shouldn't break existing code. >> >> >> >
