I didn’t mean for this to sound negative, more constructive. Oh I know how quickly things can get out of hand with spending time on open source ...

That being said, for things like “Max 7 now uses a larger buffer on this object” and making the buffer larger doesn’t actually change how the expected out of the object works, why not update it? The Max devs have a vested interest in not breaking their customers patches too. Even easier when someone has already compared and tested those differences for us developers and can greatly help guarantee making a change will not be detrimental.

--------
Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com

On Dec 23, 2015, at 8:24 AM, Dan Wilcox <danomatika@gmail.com> wrote:

Oh I know. It just seems a shame to say: "Well, somebody might have a patch somewhere from 10 years ago that relies on a 10 year old version of a library that mimics a 10 year old version  of Max running on a 10+ year old computer/os and we can't break that, ever."

For vanilla objects yeah, I get it, but for externals isn't it also reasonable able to say: "It's been 10 years maybe I might need to update that patch that uses that 10 year old external lib."

I'm not saying break things arbitrarily but, in the case of Max, they don't want to break people's patches either (and I bet there are more patches out in the wild than Pd patches). What has max changed object-wise between 4.6 & 7 that actually breaks things? I'd say very little and, if so, the whole argument is kind of moot so why not just introduce those non breaking changes made by Max?

If only we had someone who could extensively test, compare versions, and make notes about these differences. That would make not easy to see what might be a problem an what's easy to add. Oh wait, hasn't Alexandre been spending alot of time doing just that?

IE if an object historically had one output and and update adds another, how does that break old patches that only use 1 output?

enohp ym morf tnes
--------------
Dan Wilcox
danomatika.com
robotcowboy.com

On Dec 23, 2015, at 4:29 AM, katja <katjavetter@gmail.com> wrote:

On Wed, Dec 23, 2015 at 4:44 AM, Dan Wilcox <danomatika@gmail.com> wrote:
What about versioning? If people *have* to have older compatibility, then
why can’t they just run an older version of cyclone? Newer development can
take place on the current version and you can clearly note api
changes/updates in a CHANGELOG. Say tag cyclone right now as version 1.0.0
and all further development is version 2.0.*

Versioning is important but it can't solve all issues that arise when
diverging. While it is easy for a user to update to a specified
version of a library with deken, Pd patches already out there 'in the
wild' (to quote Jonathan) don't specify which version they need.

Katja