[Geany-devel] geany-plugins depends on GIO

[Lex Trotman]

On 17 November 2010 10:22, Colomban Wendling <lists.ban at herbesfolles.org> wrote:
> Le 16/11/2010 23:32, Lex Trotman a écrit :
>> On 17 November 2010 03:11, Frank Lanitz <frank at frank.uvena.de> wrote:
>>> On Tue, 16 Nov 2010 15:13:03 +0100
>>> Colomban Wendling <lists.ban at herbesfolles.org> wrote:
>>>
>>>> Le 16/11/2010 09:23, Frank Lanitz a écrit :
>>>>>
>>>>> Well, agreed. In most cases it should work fine with compiled in
>>>>> version number as most cases the API/ABI is changing with some
>>>>> major release. But of course this will go into trouble with minor
>>>>> releases as we had them with 0.19.1 or if anybody is remembering
>>>>> the 10.x ones :)
>>>>>
>>>>> Well, however. I think a simple function which returns the version
>>>>> string into plugin API would be enought or am I wrong? something
>>>>> that is just doing a return GEANY_VERSION;
>>>> I think it is better to return major, minor and micro version (or
>>>> something that fits the versionning scheme) as plain integers.
>>>> The advantage is that it becomes easy to use this version for any
>>>> check, where a string is quite tedious to use.
>>>>   geany_get_version(gint *major, gint *minor, gint *micro)
>>>> for example, or 3 variables, not sure.
>>>
>>> Well, even it looks a bit dirty in my eyes (maybe we can put this into a
>>> struct) it would solve users from use the parsing over and over again
>>> as I did inside updatechecker with
>>> static void parse_version_string(const gchar *ver, gint *major, gint
>>> *minor, gint *micro, gchar **extra)
>>>
>>> So I'm pro ;)
>>
>>
>> Just a question, shouldn't plugins be checking the ABI version was
>> what they conpiled with not the Geany version?
> I think this is not the question: Updatechecker wants to know the Geany
> version to check whether there is a newer one, it's not a plugin
> development need, but a goal.

Ah Ha!! I see, I'd missed the actual purpose of the plugin :-D

In that case I guess the three ints and some chars would be best for
relative comparison, assuming thats how Geany is going to continue to
do its versioning.

>
> Of course, to check a functionality at runtime, a plugin should use the
> API version (and then getting the Geany version is quite specific).
>
> BTW since you speak of this, I think API version should be made more
> visible. The API version in which each function appeared should appear
> in the doc rather than the Geany version it appeared in.

Agree.  But also "in which version did the functions parameters and/or
semantics change" is more important.  If that change is newer than the
plugin then the plugin shouldn't try to run.

This would make
> easier for plugin developers to know for which version check.
> Also, perhaps a compile-time check would be interesting, it would allow
> things like "if Geany version is too old for this, it's not fatal, we
> will do without" -- stop me if it already exists.

The plugin only depends on the ABI it wants to use, so in a perfect
world it would be able to check the each function it wants to call for
the version in which it last changed.  This will allow plugins to
continue to operate as long as possible without rebuilding.

At initialisation the plugin could simply present a list of functions
and Geany could then return a list of versions for them (from a table
extracted from the doc comments).  It is then up to the plugin to
avoid functions it can't use, eg by not running at all or by limiting
functionality to avoid using functions that are too new, too old or
don't exist.

Cheers
Lex

>
> Regards,
> Colomban
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>