I find Fred Jan's maintenance reasonable because sticking with current behavior means 0% of patches in
the wild will be negatively affected.  There's the possibility that his maintenance hinders Max compatibility for future
patches, but this isn't something we can quantify.

We can _estimate_ the impact of changing Cyclone behavior by taking a large sample of patches and
mining them to see what percentage would be impacting by such a change.  (We can also look specifically at how
the behavior changes, how easy it is to undo, etc.)  But obviously a change affects 1/10000 patches is different than
a change that affects 5000/10000 patches.

But doing that would take a lot of time and energy.  I'm not willing to do it, and I'm not about to tell Fred Jan to
do that after he's taken on the task of maintaining an abandoned library.  I'm also not willing to do it because I
don't think it will result in any significant improvement for porting patches between Pd and Max.  But again, that's
just a hunch about future development.

If you have the opposite hunch then do some data mining so that we can have a more meaningful discussion. 
Otherwise we're just draining Fred Jan's maintenance energies-- overestimating the potential damage of him
leaving some code untouched, and understimating all the other improvements he's doing.

-Jonathan


On Tuesday, December 22, 2015 12:56 PM, Alexandre Torres Porres <porres@gmail.com> wrote:



2015-12-22 15:25 GMT-02:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at>:
Hi anyone encouraging backward breakage,
Please make a collection of as many patches as possible, from as many public
sources as possible.

Then mine this data to get a sense of what percentage of patches would be affected
by changing a Cyclone class' behavior.

Then let's continue with conversation.

If no one is willing to do this, it's a tacit acknowledgement that Fred Jan is taking
the only sensible approach to maintaining Cyclone.

I don't think I get this, or agree. Are you saying that people who wish to break backwards compatibility should check if there's any patch out there which could be affected, and then if no patch is affected we could change it? That might be logical but not very reasonable. 

But anyway, I don't think we should narrow the discussion to this! 

I guess I might be "one" encouraging backward breakage, although I made suggestions to not break it and said that the issue in discussion (the average~ object) did not really pose this dilema - let me stress and emphasize that I don't believe this is a "A" or "B" choice, and I hope we do not really have to discuss this like that.

Katja made other suggestions on how to "meet in the middle", it is perfectly possible to change the behaviour with an argument or a message, I agree. No one here is just up for backwards compatibility breakage so let's not, please, make this such a discussion...

What really concerns me is anyone encouraging the breakage of the purpose of cyclone (compatibility to MaxMSP). I don't think this is sensible at all, it is a major change of course in the project.

Again, we're not really facing a dilema between backwards compatibility versus Max/MSP compatibility, but considering Max/MSP compatibility not a priority (even acknowledging there's a mistake that shouldn't be there in the first place) kills the main purpose of cyclone and that'ss serious. I'd say it even points to a fork in the project. If such a detour in purpose emerges from the maintenance, maybe we shouldn't call it "cyclone" anymore.

On te other hand, if one is encouraging Max/Msp compatibility breakage, maybe this person could check first if any user will be affected by that change. There's me right here, by the way :)

cheers