Le 17/11/2010 23:09, Lex Trotman a écrit :
On 18 November 2010 03:36, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 17/11/2010 02:17, Lex Trotman a écrit :
It would need the plugin to something like "dynamically load Geany", while assuming that Geany has an unstable API. This is IMHO really complicated to deal with correctly, and I don't think that not having to recompile a plugin is a sufficient gain for such a pain.
Recompiling is not (much of?) a pain for us developers, but it is a pain for other people who use Geany for non-C development. They might not even have a C development environment, especially on Windows. Using Geany or plugins should not be dependent on being able to build it.
Under a Linux distribution, it is most likely a non-power-user is using it's distribution's packages for both Geany and plugins, and the distribution should take care of such things. Under Windows, I don't think that upgrading plugins from a binary installer is much work for somebody that upgrades it's Geany.
An I personally feel quite OK about plugins for a software to evolve together with the software. But it's my opinion.
But they don't. Not even all the plugins in Geany-plugins.
The static version dependency means that either plugin development is stalled if it needs newer API, or older versions of Geany are not supported.
In fact even if no new features are used, a new geany_plugins release will no longer run with an old version.
Why? AFAIK as far as the Geany ABI hasn't changed, it should still work if the plugin depend on a compatible API number, shouldn't it?
ATM how does an older plugin know that a new API is compatible unless its been re-compiled??
Well, if the API is there it can guess it's compatible, can't it? So as a C think if all plugin's symbols are resolved, it should work.
To support older versions of Geany, plugin devs need to maintain multiple versions of their plugin and backport bugfixes, lotsa work and doesn't fit into geany_plugins combined releases. I'm not talking about very old versions of Geany, the problem happens immediately at release of a new version. Geany maintains compatibility with *ancient* versions of GTK, why then does it require itself to be the latest version?
Well, well, well... I don't really feel good with the idea of a plugin that removes a feature of itself when running with some versions of Geany. I don't think it is easily understandable for users that to get a feature of a plugin they got to upgrade Geany. But well, why not.
I guess I'm more thinking that a new plugin feature won't be available if it needs a feature that an older Geany doesn't support rather than removal of existing features.
Hum... yes, it is what I thought: given version V of Geany and version V' of the plugin, if user wants feature F that exists in version V' of the plugin, she has to upgrade her Geany to version V''.
But does new API really matters? If a plugin writer wants to keep being compatible with old Geany versions, she just have not to use new API -- as far as the ABI hasn't changed.
But ATM how does a plugin check that without being re-compiled?
What what what? :D If a plugin compiles with version 0.18 and Geany doesn't detect a problem when comparing the ABI version it was built against, it IS compatible, no? And if the same plugin is compiled against Geany 0.19 (assuming the ABI hasn't changed), it will still work with Geany 0.18...
Regards, Colomban