On Thu, 18 Nov 2010 09:55:35 +1100, Lex wrote:
2010/11/18 Enrico Tröger enrico.troeger@uvena.de:
On Wed, 17 Nov 2010 19:52:40 +1100, Lex wrote:
Hey,
I don't want to go too deep into this discussion, just my cents:
To keep it shorter, I'm 100% agree with Colomban's statements.
As Geany is getting more and more functionality in plugins there needs to be more thought in general about the need to lock Geany versions and plugin versions.
Yes. But not at all costs.
If they are locked together then users can't upgrade Geany until their plugins support the new version and can't upgrade plugins without upgrading Geany.
As I said in another post, as Geany is used for more than C development it is becoming less acceptable to assume that all users can re-compile Geany or plugins so any system needs to work at runtime as well as at compile time.
As already said, most users probably use distribution packages and/or Windows binaries. I think we can ignore (don't get me wrong here :D) Windows users as there updating Geany is really simply: download installers, execute them, done.
Assuming that Geany and all plugins have been updated, that means that plugin devs have to update the plugins every time Geany updates and at the same time. Effectively Geany and geany-plugins and any plugins not in geany-plugins have to be the same package since they have to remain in lockstep.
Why? The last releases indeed broke ABI compatiblity each time (IIRC). But it's not meant to be the normal case. At some point the plugin API should be stable enough to not break ABI every now and then. And once we reach this point, I don't see any required lockstep here.
The distribution packages users also can easily upgrade provided that the package maintainers do their job, out of our responsibility.
But they can't package anything unless we provide them with updated everything, so giving Geany and plugin devs more work. Or you get the
We are talking about releases, right? Some time ago, we said that at least for now we try to keep Geany and Geany-Plugins releases together as long as it's possible. That's not strictly a technical requirement, more or less just for users' and developers' convenience. Again, AFAIK there is no technical requirement.
problems that have currently happened with Debian where some plugins were not updated in time to make the release so they didn't get in the package :-( Thats not Debians fault.
Side note, the geany-plugins 0.19 package entered Debian Squeeze last weekend because of the heavy efforts of its Debian maintainer. Doesn't relate to the discussion but is worth mentioning anyway :). Thanks Evgeni!
And then, there are those users who compile from source. I think it doesn't matter for which languages they use Geany, either the compile Geany from source or they do not. If they do, they can do it again if anything is incompatible, especially for SVN version users.
Agree, I'm not worried about people like you and me who can compile things, we don't count :-)
Bah, always hearing the same: you don't count!
(j/k)
Don't get me wrong, I'm not against making compiling Geany +Plugins even more easy for users. But at some point I think code maintainability (is this a real word? :D) is also important.
Maintainability is indeed a word and an important one, and by
:)
decoupling plugins and Geany you reduce maintenance since things don't
I don't see any strict coupling you are talking about. Except the above mentioned release policy but this isn't that strict.
So there needs to be thought about how to allow any version of Geany and any version of a plugin to continue to work as long as the functions that they *use* have not been changed. This means that a single API/ABI number for the whole interface is not enough, it needs to be per function. Then smart plugin developers can make their plugins adapt themselves at runtime to the features available from Geany.
This leads to tons of #ifdefs or even worse,
Only if a plugin dev decides to use the facility, otherwise the plugin just says, "oh, wrong version of the function, sorry I can't run." If
This already happens, partly on compile-time, partly on runtime at loading the plugin. Even though Geany says: "oh, plugin can't be loaded, sorry'.
if you really want to have
per-function checks at runtime, if conditions in the code. I think this makes maintenance of such code much harder and so it easier tends to break which makes users even more sad.
There are lots of requests by plugin devs for access to more of Geany, that changes the API/ABI version and that should make all other plugins fail until they are updated (but doesn't always, which is
This already happens, at least for API/ABI changes. For API additons, it doesn't matter.
Regards, Enrico