Hum, has this been resolved? I admittedly didn't read everything, but we definitely at the very least need to bump ABI (even if indeed it's not a perfect solution).
IMO, @elextr's idea of rejecting older APIs altogether is not a bad one. It's a bit annoying on plugin authors, but I totally agree with @elextr that it's **entirely unacceptable** that we might happily load plugins that are buggy not because they are not written correctly, but because they have not been updated to be compatible. I think we ought to find a fix, even if it's inconvenient. (and yes, I know bumping ABI isn't actually enough to be safe). Also, really concerned authors could likely even `#ifdef` their way out of it for supporting older APIs, if they really want to go to the trouble. Actually, one (very annoying) fix could be overriding `scintilla_send_message()` to patch up the calls so it works as it used to. It's not as efficient, and it's a pain to maintain, but at least it would fix it. But then, we could just as well "unpatch" Scintilla itself and live forever with that (and bear in mind that it makes the Scintilla documentation slightly off regarding our version). A probably better option is to scratch our heads a couple times as to why Neil introduced such a dramatic change in a point release of an otherwise hugely stable component, and then come to terms with it. Then, maybe we cant take the opportunity and decide on the N+1 version number to be 2.0 indeed, make a big bold announcement, and require *all* plugins to be *manually* patched, even if that means annoying authors. It's not actually an uncommon practice that to require authors to declare the range of versions their plugin is supporting, even if it means authors have to get ahead of new versions. > Maybe the wrappers need expanding, I know Geany mixes it too, but we have > (possibly re-)learned a lesson, the wrappers are more than convenience, they > allow hiding changes to Scintilla APIs. I don't think we should rush in and > change Geany or vimode, but progressively over time move that way and put a > note in HACKING and plugin API docs to that effect. Well, for one thing, it won't really scale (lots of APIs, new APIs, etc.). Secondly, we'd just move the burden of backward compatibility on Geany, whereas we until then have had no trouble trusting Scintilla for this. And at some point if either Geany or Scintilla evolve into *requiring* some API-facing changes, we'll have the same problem again, *and* a million wrappers to update. A possible precaution could be reviewing all of *Scintilla*'s API and suggest Neil changing the "bad" ones **now** so we don't know we're carrying more bad APIs that somebody will want to change in the future :slightly_smiling_face: -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3095#issuecomment-1436783552 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/issues/3095/[email protected]>
