Hi Dan, How do you handle versioning?
On Wednesday, October 14, 2015 3:18 PM, Dan Wilcox <danomatika@gmail.com> wrote:
That’s why one idea with deken is to install an “extended” meta package which installs most (if not all) of the libs that came with pd-extended. I don’t think it’s too hard to ask a user to open the plugin and install a single package. Also, the cross platform issue will be fixed in time. Thanks for debugging!
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Oct 14, 2015, at 9:22 AM, rolfm@dds.nl wrote:
it looks like the future of pd-extended is going to be 'deken'. what to do then about portability?
i make patches for people who don't know a lot about programming. plus they are on Mac, i'm on Windows. one time downloading the right version of Pdext is enough; i can give them my patches and they just run them. when i make changes, new features: there's no hassle for them.
using Vanilla & deken is something else. declaring a library in the patch is not enough. including the library in the patch-package works only on the same type of OS; Windows & Windows, Mac & Mac, (Linux & Linux?).
one method could be a deken-connected feature to automatically download a declared lib when it's not present. what about updates or changes in a lib in that case?
the organisation of pd-ext somehow included a kind of gate-keeping, which resulted in a stable Pd-system. i'm still using Pdext 42.5 and the included libs a lot (because of the old machines in my installations). the same libs are functional in Pdext 43.4. so one could argue that there's no great need for a portability design. just download everything that's necessary (and available) and it will work for quite some time.
? rolf
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list