Re: [pygame] [PLEASE TEST]: New locking code

["Charlie Nolan" <funnyman3595@xxxxxxxxx>]

On a major release, yes, but not on a bugfix release.
-FM

On 6/10/08, Brian Fisher <brian@xxxxxxxxxxxxxxxxxxx> 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 <renesd@xxxxxxxxx> 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
>> <brian@xxxxxxxxxxxxxxxxxxx> wrote:
>> > Even bad broken code?
>> >
>> > On Tue, Jun 10, 2008 at 4:09 PM, René Dudfield <renesd@xxxxxxxxx> 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.
>> >>
>>
>