[PD-dev] Pd-extended EOL?

[Hans-Christoph Steiner]

On Nov 9, 2015, at 2:56 PM, IOhannes m zmoelnig wrote:

> hi hans,
> 
> great to hear from you!
> 
> On 2015-11-09 14:49, Hans-Christoph Steiner wrote:
>> FYI, for anyone interested, it would not be hard to do a Pd-extended update if it is just a matter of updating the libraries.
> 
> what i would find more interesting: how hard would it be to update the
> PdX-core to Pd-0.47? that is, the patcheset against Pd-vanilla.
> 
> i once had a look at the PdX repository (which is based on miller's
> vanilla Pd), but even for PdX-0.43 the two repositories had diverged by
> (iirc) a few hundred commits, which makes it highly impractical to
> rebase/reapply/cherry-pick.
> 
> is there any meta-description available of the diffs between PdX and Pd?

For a long time, I used a git workflow that kept the Pd-extended changes as a set of patches on top of vanilla, you can see that in the 'patch_series' branch.  You can see that in the history.  I ultimately abandoned that because there were too many commits from vanilla that I had to remove in order to keep things working.  So I switched to treating vanilla as a source of patches which I included into the pd-extended master.  I regularly submitted patches that didn't rely on the Pd-extended stuff to the patch tracker.  Many of those were ignored for years.  I have no idea the current state of them.

That workflow is documented here under "Pd-extended":
https://puredata.info/docs/developer/GitWorkflows

As for syncing up Pd-extended with the latest vanilla commits, that is a manual process of reviewing them and including them.  If I remember correctly, basically anything that touches an object, e.g. src/x_list.c, src/d_soundfile.c is directly accepted.  The objects in extra/  actually removed from pd-extended.git, so those changes can all be ignored.  I generally automatically accepted changes to the DSP core too.  Stuff related to the GUI definitely needs to be carefully reviewed.

.hc