[Geany-devel] geany-plugins depends on GIO

[Enrico Tröger]

On Thu, 18 Nov 2010 09:55:35 +1100, Lex wrote:

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

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

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20101118/0fd6282b/attachment.pgp>