Le 19/01/2011 18:45, Dimitar Zhekov a écrit : > On Tue, 18 Jan 2011 23:13:51 +0100 > Enrico Tröger <enrico.troe...@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 _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel