[L2Ork-dev] call for mentorship: version bump

[Jonathan Wilkes]

On Sat, Jul 11, 2020 at 12:17 PM Albert Graef <aggraef at gmail.com> wrote:
>
> 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?

Yes. The new code accepts either a float or a symbol in the iemgui arg
slot for colors. Additionally, old patches which use
integers as arguments to the "color" method will continue to work as
normal. (Though I do spit out a warning if the user tries
to mix symbols with floats in those 3 arguments.)

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)?

Yes. Pd Vanilla has for awhile accepted both symbol and float args in
the slot for the iemgui colors. And I can confirm it
reads what I'm writing in the feature branch for Purr Data.

>
> 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. ;-)

[; pd compatibility 0.47( should do the trick. For "Save with lossy
iemgui color format" we could just switch to that
version and then switch back. But I'd want to remove that after a few versions.

-Jonathan

>
> 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/
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev