[PD] consolidate backward- and MaxMSP compatibility in Cyclone (was: Purpose of Cyclone)

Dan Wilcox danomatika at gmail.com
Wed Dec 23 16:44:15 CET 2015


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 <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Dec 23, 2015, at 8:24 AM, Dan Wilcox <danomatika at 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 at gmail.com> wrote:
> 
>> On Wed, Dec 23, 2015 at 4:44 AM, Dan Wilcox <danomatika at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151223/e2efc360/attachment.html>


More information about the Pd-list mailing list