[L2Ork-dev] call for mentorship: version bump

[Albert Graef]

Hi Jonathan,

I'd be for any change that improves Purr Data, but (as usual) I'm concerned
about patch format compatibility with vanilla. Just to be clear, did I
understand correctly that old patches (from either vanilla or older Purr
Data versions) would still be *read* without a problem? And is it true that
the (current and future versions of) vanilla will be able to *read* those
new-format patches produced by future Purr Data (even if it does not write
them at present)?

That's the most important question for me. Still, I'd *strongly* recommend
adding an option to the prefs that will allow saving a patch in the old
format, to allow for exchange of patches with colleagues and friends who,
for some reason, might still be running an old version of Purr Data or
vanilla. Or, better yet, offer a corresponding option in the File menu,
i.e., a variant of "Save as..." but named "Save as old format...", "Export
to old format...", or something similar. That should be fairly easy to
implement. If we don't do this, my crystal ball tells me that there are
going to be a *lot* of complaints. ;-)

Finally, concerning the version change: As I said various times before, I'm
not a big fan of semantic versioning, but I can understand the rationale
behind it. With a disruptive change like this, yes, that'd certainly be a
case for a major version bump in the semantic versioning scheme.

Cheers,
Albert


On Sat, Jul 11, 2020 at 5:23 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> On Fri, Jul 10, 2020 at 5:40 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
> wrote:
> >
> > Hi all,
> >
> > I'm porting the "#ffffff" color syntax from Vanilla.
> >
> > The thing is-- this won't be forward compatible because new patches
> > will save iemgui color args as symbols. Previous versions will refuse
> > to read in the new args correctly because they check for floatargs in
> > those color slots of the arguments. This can give surprising behavior
> > to users one or two versions behind-- they'll see breakage in colors,
> > label display, and possibly other problems with patches created in the
> > newer version of Purr Data. Worse, there's no way to force an error to
> > be reported in the old versions, as the iemgui arg-loading code simply
> > fails silently if it gets wrong arg number and/or types.
> >
> > Vanilla's solution was to put a big "FIXME" comment while turning off
> > the ability to save the new symbolic color args for the time being.
> > This creates an insidious bug where users are already inputting the
> > precise "#123456" colors but continue getting the lossy behavior of
> > the weirdo integers.
> >
> > Is this a case for a major version bump? Anything less and I'm afraid
> > users on older versions won't realize the subtle change in file
> > format.
> >
> > Honestly, I'd rather add a line to the file format that crashes the
> > old versions than have subtle wrong behavior like this.
> >
> > Suggestions?
>
> I'll answer my own question here:
>
> We've actually had Vanilla's "version" global method since 2007. That
> allows
> us to do this:
>
> 1. For the next release, hoist a bare message "pd version $whatever"
> to the top of each saved patch file.
> 2. If the version is greater than zero, all older versions of Purr
> Data will output an informative error telling
> them, "file format newer than this version of Pd (trying anyway...)".
> It's printed as an error in red, so that should
> be as obvious as we can get given the circumstances.
> 3. When people come to the list inquiring about it, we can tell them
> to upgrade Purr Data.
>
> This will be a blocker for the next release, so if anyone want to take
> a stab at coding it that would be much
> appreciated.
>
> Note: Vanilla added some code to compare against the current version
> like "0.47", so that could be handy in the
> future.
>
> -Jonathan
>
>
>
> >
> > -Jonathan
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev



-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef at gmail.com, web: https://agraef.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200711/cd0f9ca6/attachment.html>