[PD-dev] Pd-extended EOL?

Roman Haefeli reduzent at gmail.com
Thu Oct 1 10:12:02 CEST 2015


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20151001/e88775fb/attachment.sig>


More information about the Pd-dev mailing list