[L2Ork-dev] call for mentorship: version bump

[Albert Graef]

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

> Yes. The new code accepts either a float or a symbol in the iemgui arg
> slot for colors.


Good.

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

Is that branch online somewhere? I couldn't find it at
https://git.purrdata.net/jwilkes/purr-data, and I'd really like to give it
a go myself.

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


I'm not sure I understand. You simply put that message into the patch and
then it saves it in the old format?

But I'd want to remove that after a few versions.
>

If by "a few versions" you mean "a really long time", then I'm alright with
it. ;-) See, some people might be stuck with really old Pd versions for all
kinds of different reasons, like running on really old hardware and/or a
really old Linux version. So I'd say that even though we don't want to be
held back by all those legacy systems, as long as we can at least provide
some kind of compatibility with them on the patch format level, we should
aim for that.

Albert


> -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
> _______________________________________________
> 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/890544f0/attachment-0001.html>