On Wed, 2015-09-30 at 10:25 -0600, Dan Wilcox wrote: > Since Pd-Extended is basically EOL at this point, maybe we should > discuss more formal plans on a transition to Pd-vanilla+deken. I know > this has been happening informally, but I think it would be cool to > come up with some sort of timeline and list of things to do to reach a > relative parity,
I'm not sure what you mean by 'relative parity'. Things probably won't be the same with deken, I assume. In Pd-extended times, people would have created patches with whatever externals, they even didn't have to know what externals their patches used. It was sufficient to specify "Pd-extended" as a dependency for running the patch. With deken, the author needs to specifically list all externals when sharing the patch. To me shifting to deken means raised awareness about externals. It also means that it provides a path to get rid of unmaintained and/or buggy stuff. There is no need anymore to install deprecated stuff per default for anyone just for the sake of keeping backwards compatibility. In that regard, the deken era will be different from the Pd-extended era. If by 'relative parity' you mean availability of all the externals the last version of Pd-extended came with, this might have been reached already. Search for 'extended' in deken. It shows a lot of (all?) externals directly packaged from Pd-extended. Many thanks to IOhannes for uploading all those. Roman
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
