[Geany-devel] geany-plugins depends on GIO

[Lex Trotman]

2010/11/18 Enrico Tröger <enrico.troeger at 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.

> 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
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.

> 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 :-)

> 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
have to keep on being updated to ensure that they work, instead they
make the decision themselves.

>
>>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
I was a plugin dev I'd check all version numbers in my plugin init
function and fall over if incompatible or at most would have only a
couple of flags that remove new functionality if required versions are
not available.

 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
risky).

Cheers
Lex

> IMO.
>
> Regards,
> Enrico
>
> --
> Get my GPG key from http://www.uvena.de/pub.asc
>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>