[L2Ork-dev] Getting ready for GSoC coding to begin
aggraef at gmail.com
Thu May 28 18:18:09 EDT 2020
Hi Jonathan, and everybody,
Well, I argued my case. IMHO, the public API didn't change, since this was
never a documented feature. It's a bug which was now fixed. For me it
doesn't matter how the bug came into being, whether it was introduced
deliberately or by accident.
But that's just me. I guess I'm also just getting old, and don't like the
inflation of version numbers that semantic versioning brings about. I guess
that once we're at version 20.0.0, though, even my mind will be at ease, so
you might as well just bring it on. ;-)
Oh, and btw, since I didn't introduce myself properly to our 2020 GSoC
participants before: Welcome to all of you!
I'm listed as a co-maintainer for this project because I did contribute a
fair amount of code and bugfixes at various times, and I currently maintain
the Github mirror of Purr Data including the
https://agraef.github.io/purr-data/ website and wiki there, as well as the
JGU package repositories on OBS for different kinds of Linux systems. JGU =
Johannes Gutenberg University at Mainz in Germany, which is the university
where I work, and I am the head of the Computer Music (a.k.a.
Music-Informatics) research group there. We've also hosted the Linux Audio
Conference (LAC) in 2015 and the first-ever Faust Conference (IFC) in 2018,
some of you might have heard of these before.
If you couldn't tell already, I'm a big fan of Purr Data and use it heavily
in my courses, and I have been using Pd-l2ork for quite a few years before
that. I'm an ardent Linux and open-source lover -- Linux user since 1993.
Yes, I'm that old. ;-) I also have a personal page on Github where you can
find some of my other projects, see https://agraef.github.io/.
Unfortunately, right now I'm a bit swamped at work (extra duties because of
all the digital/remote teaching that's going on), so I'm afraid that I
won't be able to help as much with the GSoC as I'd like to. But I'll try to
follow the bug reports, merge requests and other updates as much as I can,
and chime in with my 2 cents whenever I find the time!
On Thu, May 28, 2020 at 6:26 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
> On Thu, May 28, 2020 at 3:44 AM Albert Graef <aggraef at gmail.com> wrote:
> > On Thu, May 28, 2020 at 8:00 AM Albert Graef <aggraef at gmail.com> wrote:
> Albert Graef via disis.music.vt.edu
> 3:44 AM (8 hours ago)
> to l2ork-dev
> On Thu, May 28, 2020 at 8:00 AM Albert Graef <aggraef at gmail.com> wrote:
> > While we're at it, there's yet another problem: I doubt that rev.
> 779f31dc entirely fixes the issue reported in #299.
> > [...]
> > Heck, apparently even Miller decided to fix this at some point, and he
> usually rejects *anything* which breaks backward compatibility in vanilla.
> This was always an l2ork branch of code IIRC:
> 1. Ico added the bang method to pd-l2ork
> 2. I wrote Ico about the ambiguity wrt "symbol bang", added an issue,
> and labeled the issue "good-first-bug"
> 3. Zack fixed that bug to get some practice submitting a merge request
> So as I understand semantic versioning:
> 1. Ico added a feature: minor version bump
> 2. I took away that feature: major version bump
> Someone who has used Purr Data for years can then look at the major bump
> from 2 to 3 and take care updating given that there's a breaking change.
> I guess I'm using semantic versioning to communication information about
> pd-l2ork changes, and you're using it to communicate information about
> Not sure what the path forward is, but does all this sound correct so far?
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
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...
More information about the L2Ork-dev