[L2Ork-dev] call for mentorship: version bump

[Albert Graef]

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

> https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/423


Oops, sorry, I overlooked that. Thanks. I'll have a look and test it out
once you've resolved the merge conflict on regression_tests.pd.

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

Ah, that's better than my suggestions, since it makes the compatibility
requirement visible in the patch.

I still don't quite understand why you want to remove that feature again
rather sooner than later. Does it incur a lot of technical debt, i.e., is
it a lot of extra work to support that feature going forward?

Also, I'm trying to understand the implications of removing that feature
again. Will it then become downright impossible to open patches written by
Purr Data in older Pd versions? Or will olden days Pd load them anyway,
just with the colors looking a bit out of whack? I don't think that the
latter is much of a problem. We've had forward compatibility issues like
these for a while already, that's just what we call progress over here. ;-)
As long as you can still load the patch in old Pd, and it more or less
works as intended with the usual amount of fiddling, most people should be
fine.

Regardless of what I do with the symbolic colors as saved in a patch
> file, I'd still be implementing the "[color #ffffff(---[iemgui]"
> syntax for setting colors at runtime. That feature is non-trivial to
> backport on save, so any newer patches
> using it will necessarily break for users who are stuck on old Pd versions.
>

Yes, I understand that, and I think that's fine. Rendering a patch
completely unreadable in old Pd by just saving it in Purr Data would be a
different matter, however; most people would likely consider that a bug.

Albert

-- 
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/20200712/16bc46cb/attachment.html>