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