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.*
This seems to work fine for all sorts of software libraries and deken should make it much more possible in pd.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 22, 2015, at 7:06 PM, pd-list-request@lists.iem.at wrote:
From: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> Subject: Re: [PD] consolidate backward- and MaxMSP compatibility in Cyclone (was: Purpose of Cyclone) Date: December 22, 2015 at 4:46:29 PM MST To: Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> Cc: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at>
If I may make a suggestion - when I find that an object isn't terribly well designed (for example my own qlist :) I make another one, with another name, that does the job better (text).
cheers Miller
On Tue, Dec 22, 2015 at 08:51:03PM -0200, Alexandre Torres Porres wrote:
Well, newer patches with newer functionalities not working in older versions is how things go anyway, right? Vanilla 0-46 patches don't run in 0.45 and so on... there's no way around that I guess.
the dual outlet layout with message left and signal right is rather unusual.
But I think it's also simpler and more straightforward than introducing flags, arguments and all. It might be unusual, but there are already some objects with similar design, I actually thought of that because of [sampstoms~] and [mstosamps~] - it'd be basically the same design.
cheers
2015-12-23 1:44 GMT-02:00 Dan Wilcox danomatika@gmail.com:
What about versioning? If people *have* to have older compatibility, then why can’t they just run an older version of cyclone?
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...
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.*
This seems to work fine for all sorts of software libraries and deken should make it much more possible in pd.
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...
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...
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.
I'm thinking about whenever I create [wrap] in Pd-Extended 0.42-5, it shows the error: *A new incompatible [wrap] object was introduced in Pd 0.42.* *... you might be able to track this down from the Find menu.*
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.
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.
But, hey, well, cutting to the chase, I back you up on this one...
cheers
Actually one of the problems with extended was that it loaded *everything* by default, so people aren’t used to specifying required libs. Imagine if [declare] or [import] could also specify lib versions ...
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 22, 2015, at 10:05 PM, Alexandre Torres Porres porres@gmail.com wrote:
Now people who used extended will have to install libraries on their own with deken and need to know what's going on.
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
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?
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
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@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
On Wed, Dec 23, 2015 at 4:24 PM, 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?
It doesn't, and it sounds better than:
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?