<div dir="ltr"><div>2015-12-23 1:44 GMT-02:00 Dan Wilcox <span dir="ltr"><<a href="mailto:danomatika@gmail.com" target="_blank">danomatika@gmail.com</a>></span>:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">What about versioning? If people *have* to have older compatibility, then why can’t they just run an older version of cyclone?</div></blockquote><div><br>We're not really even at a real discussion where people would *have* and *need* to stay with an older version of cyclone by the way. I'll get to that...<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">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.*<div><br></div><div>This seems to work fine for all sorts of software libraries and deken should make it much more possible in pd.</div></div></blockquote><div><br></div><div>Dan, if I fully get you, I agree and had thought about it. I'm just also open to those who think differently and care a lot about the compatibility deal, so I'm also suggesting simple solutions for "everyone to be happy". But if it was up to me...</div><div><div><br></div></div><div>Some of the discussion here is based on the worries of breaking patches as if Pd as if Pd users don't have to be savvy on managing versions and external libraries, as if they'd be tied up whenever a change was made. It's almost like as if one would have to search all the patches in the world, and if one that would be affected was found, the case should be rested, and nothing could be done...<br><br>But let's be reasonable, worls is crazy, life is crazy and also a bitch, crazy stuff happens all of the time in the Pd world (and in the software world) and we have to manage that. Now people who used extended will have to install libraries on their own with deken and need to know what's going on. <br><br>I'm thinking about whenever I create [wrap] in Pd-Extended 0.42-5, it shows the error: <u>A new incompatible [wrap] object was introduced in Pd 0.42.</u></div><div><u>... you might be able to track this down from the Find menu.</u></div><div><u><span style="white-space:pre-wrap"> </span>For a backwards-compatible version, use [zexy/wrap]</u></div><div><u><br></u></div><div>That's it, a simple warning, and deal with it... change your patches if you have to. Change your version, read the changelog, read the help file. Just point the issue and solutions if they actually show up.</div><div><br></div><div>The crazy thing is that, objectively, we're not really even at a real issue where people would *have* and *need* to stay with an older version of cyclone. The only thing that came up (a change in behaviour in [average~]) is easily fixable and manageable... it's not like the patch would break beyond reparability, and even if no message is added to the Pd window (regarding the new functionality of the object nor anything in the help file), error messages in the console would still point to the problem (signal outlet connected to control inlet)... there you go, find te error and just use a snapshot~ to convert to data then.</div><div><br></div><div>But, hey, well, cutting to the chase, I back you up on this one...</div><div><br></div><div>cheers</div></div></div></div>