Le 19/01/2011 18:45, Dimitar Zhekov a écrit :
On Tue, 18 Jan 2011 23:13:51 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
In fact, I propose to do exactly this: all plugins of the combined geany-plugins releases should have the version of the geany-plugins release itself. Everything else would just cause confusion, IMO.
So we are going to have my_plugin version 0.5, followed by 0.20, and then 0.6 or 0.7? Which one is the latest?
I personally don't think that g-p is only a release facility, most plugins that are part of it are also developed on g-p, etc., and generally don't have standalone release (AFAIK).
Or, if the plugin version always matches Geany version (not in releases only), then the plugins have no their own version at all.
That's why I don't really feel good with the combined version (though I don't really care finally): plugins don't really have a version that shows something about their status. E.g., g-p 0.20 is the first release of WebHelper, so the version 0.20 don't seem to be justified.
However, again, I don't really care because I think both ways have arguments for them.
I see Enrico doesn't like it, but maybe we should have something like:
plugindata.h:
#ifndef PLUGINS_VERSION #define PLUGINS_VERSION " - Custom Build" #endif
myplugin.c:
PLUGIN_SET_[TRANSLATABLE]_INFO(..., "0.5" PLUGINS_VERSION, ...)
plugins build system:
gcc ... -DPLUGINS_VERSION=" - Geany Plugins 0.20"
The main problem I see is translations: it would be hard to make this support translations. It would basically need a new arg to PLUGIN_SET_INFO, like, don't know, origin, but this would break the backward compatibility of the macro -- or add a new one, but...
And regarding my first point above, I'm not really sure about it. However, it looks better than 0.0.1-gp0.20.
Cheers, Colomban