Hi!
On Sun, Feb 7, 2021 at 5:59 PM Lloyd Konneker via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:
> The v3 PDB API has changes for multilayer capability.
> For example this signature change: gimp-edit-copy(drawable) =>
> gimp-edit-copy(drawableArray).
> This breaks some scripts in the GIMP repository and some third party
> plugins.
>
> To provide backward compatibility means allow existing scripts to work for
> a defined period.
> (say from 2.99 until 3.1).
>
Just for the record, there are no such versions: 2.99 and 3.1. Or to be
accurate, these are dev versions, they don't "count". Whatever is in 2.99
and whatever will be in 3.1 doesn't matter but for testing. We don't mind
too much broken stuff in these (we obviously prefer non-broken stuff, but
this won't stop us from releasing something for people to test the rest,
i.e. what is not broken).
As for API in particular, it means that API compatibility is a non-existent
concept there. We are heavily testing. The API may end up broken even
between 2 micro releases (like 2.99.4 to 2.99.6). This is what these
versions are for. What matters is only that we get the right API for GIMP
3.0.
That allows users time to adjust their scripts.
>
It had been decided long ago that the API could break for our GIMP 3.0
release. I mean, the multi-layer related functions you give are only the
tip of the iceberg. There are so many more changed functions, and in
particular all the base API for plug-ins are changed anyway. Now the old
base API don't even exist anymore. So anyway all plug-ins will have to be
updated. It's not even an "if" anymore, and it's not even related to
multi-layer selection (even without this, all plug-ins will have to be
updated).
I mean, it's already too late. We have not just started or anything. This
work on base API changes started more than 2 years ago (after we released
GIMP 2.10.0) and reverting this (losing 2+ years of work by several people
and using probably just as much to bring compatibility back) is not an
option as far as I'm concerned!
> If we don't provide backward compatibility, it is a logistics problem:
> third party script authors must prepare an updated copy of their scripts,
> and change over immediately when they change from 2.10 to 3.0.
>
Which is also why we have started to talk about this long before, made news
about this on GIMP website and we started to release dev versions. The
current dev API is unstable (as already said), but it's still close to what
will be released as stable. So plug-in developers are very welcome to start
porting. Whatever will change between now and finale stable GIMP 3.0 likely
won't be as much as what already changed between 2.10 and current dev
version.
We also plan to document the main changes, with porting docs, tutorial and
whatnot.
And also we hope to have the new extension platform by the time we release
GIMP 3, to help people port their plug-ins and upload them.
In the end, the change won't be so complicated. It may look scary, but in
the end, I don't think even the most complicated plug-ins will need much
more than 30 min to be ported. Ok maybe 1hour if rlly you made a
hugely complicated plug-in, I don't know. Talking from experience of having
participated to port many of our core plug-ins.
> Some scripts in GIMP 2.99 are broken now since the API was changed but
> scripts were not updated.
> If we provide backward compatibility,
> the GIMP developers can fix the scripts in the repository at their leisure.
>
Are you talking about third-party scripts or the ones we provide? If the
core ones, of course we should port them before release. But not providing
a compatibility layer again. As said, GIMP 3 is our chance to improve our
API, 25 years of cruft, 25 years of evolution, new features, new usages, so
many things different. The goal is not to continue with double the mess.
Like if we talk about multi-layer related API, what? Do we want to propose
every layer API in double now? Both multi and single layer? Then do the
same when we finally make vectors and channels multi-selectable?
I'm not saying what you say is wrong. Of course, in an ideal setup, we try
to never break any past API. But in this ideal setup, we are more than a
handful of contributors. Right now, trying to do what you propose would be
like releasing GIMP 3.0 in 5 years. I don't think anyone wants this.
So yeah this is why we just decided long ago that API breakage was allowed
as it was a major version update. We don't do useless API breakage, but for
stuff like multi-layer selection, this just makes sense. It will be a new
ability of GIMP 3. Nobody wants our API not to be able to access this
feature. And we don't want to maintain double the functions.
> Because the name has stayed the same but the signature changed,
> to provide backward compatibility could be considered
> a problem of overloaded functions.
>
> One backward compatible solution is to implement overloading in scriptfu:
>
