Hi together, in special plugin developers ;)
We currently are in the situation, that a user just sees the Geany-Plugins version when reporting bugs [1] but in the plugin manager in Geany just sees the version of the plugin itself. This might be confusing when the user doesn't remember which version of Geany-Plugins he actually has installed.
Some plugins already have the same version as Geany-Plugins. This isn't that good anymore when a new plugin arrives in the Geany-Plugins project. Imagine before joining Geany-Plugins the version was 0.0.3 and after joining it directly jumps to 0.21. Here are some alternate suggestions:
* change the version string for each plugin, e.g. 0.0.1-gp0.20 * change the text in the description (something like "this is foobar 0.0.1 brought to you by Geany-Plugins 0.20")
They additionally would fix another issue which will come up the more plugins Geany will get: Differing between the "provider" of the plugin - was this Geany-Plugins or was it delivered with Geany, or is it a completely other third-party plugin?
Maybe someone of you has also suggestions or thoughts on this, please let us know. :)
Regards, Dominic
[1] https://sourceforge.net/tracker/?group_id=222729&atid=1056532
On Tue, 18 Jan 2011 22:57:48 +0100, Dominic wrote:
Hi together, in special plugin developers ;)
We currently are in the situation, that a user just sees the Geany-Plugins version when reporting bugs [1] but in the plugin manager in Geany just sees the version of the plugin itself. This might be confusing when the user doesn't remember which version of Geany-Plugins he actually has installed.
Some plugins already have the same version as Geany-Plugins. This isn't that good anymore when a new plugin arrives in the Geany-Plugins project. Imagine before joining Geany-Plugins the version was 0.0.3 and after joining it directly jumps to 0.21. Here are some alternate
I don't see a problem here. 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.
- change the version string for each plugin, e.g. 0.0.1-gp0.20
IMO way too complicated.
- change the text in the description (something like "this is foobar
0.0.1 brought to you by Geany-Plugins 0.20")
Brrr, nonono.
Regards, Enrico
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?
Or, if the plugin version always matches Geany version (not in releases only), then the plugins have no their own version at all.
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"
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
On Wed, 19 Jan 2011 19:26:02 +0100, Colomban wrote:
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?
0.20. I was never convinced maintaining plugins within g-p and outside is a good idea. AFAIK there are only a few plugins for which this actually matches (geanylatex, geanyvc). I just fail to see how this could be an advantage. I only see the many disadvantages beginning at users' confusion and ending at duplicate maintenance efforts. And for plugins which are part of the combined geany-plugins project, these should all have the version of the g-p project itself as their are released together as one big package. What's the point if you bump the version of your plugin X within the g-p project to 0.4.2 if it's ever only released as part of g-p which also has a version number? Not to mention the mess for package maintainers.
Please note, it's just my opinion. I won't decide anything.
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).
Ack.
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.
Do any version numbers really represent the project's status? I agree in a ideal world this should be the case but I'd also say that in most of open-source projects version numbers are something more like just a statically increasing number, preferrably starting with 0 :). I personally, don't care about version numbers of other projects, to judge the project status and/or quality, code reviews, ChangeLog or NEWS items and usability are more important and more meaningful, based on my personal experience.
Regards, Enrico
On Wed, 19 Jan 2011 20:13:03 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 19 Jan 2011 19:26:02 +0100, Colomban wrote:
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?
0.20. I was never convinced maintaining plugins within g-p and outside is a good idea. AFAIK there are only a few plugins for which this actually matches (geanylatex, geanyvc).
Only geanylatex is left here. geanyVC is part since about 0.18.1
I just fail to see how this could be an advantage. I only see the many disadvantages beginning at users' confusion and ending at duplicate maintenance efforts. And for plugins which are part of the combined geany-plugins project, these should all have the version of the g-p project itself as their are released together as one big package.
I'm fine for dong this with the plugins developed inside the combined project. I will not do it for geanyLaTeX as I want to keep freedom to do independent releases.
Cheers, Frank
On Wed, 19 Jan 2011 21:25:54 +0100, Frank wrote:
On Wed, 19 Jan 2011 20:13:03 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 19 Jan 2011 19:26:02 +0100, Colomban wrote:
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?
0.20. I was never convinced maintaining plugins within g-p and outside is a good idea. AFAIK there are only a few plugins for which this actually matches (geanylatex, geanyvc).
Only geanylatex is left here. geanyVC is part since about 0.18.1
Sorry for the wrong information. I just had a look at the geany-plugins repository and there is still the geanyvc directory. Maybe this could be removed?
I just fail to see how this could be an advantage. I only see the many disadvantages beginning at users' confusion and ending at duplicate maintenance efforts. And for plugins which are part of the combined geany-plugins project, these should all have the version of the g-p project itself as their are released together as one big package.
I'm fine for dong this with the plugins developed inside the combined project. I will not do it for geanyLaTeX as I want to keep freedom to do independent releases.
Nobody will hinder you from doing that. I just said I don't see any advantage of this but my opinion regarding this is not new and I expressed it a couple of times already in the past. Since it's your plugin, it's your decision.
Regards, Enrico
On Thu, 20 Jan 2011 21:09:54 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 19 Jan 2011 21:25:54 +0100, Frank wrote:
On Wed, 19 Jan 2011 20:13:03 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 19 Jan 2011 19:26:02 +0100, Colomban wrote:
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?
0.20. I was never convinced maintaining plugins within g-p and outside is a good idea. AFAIK there are only a few plugins for which this actually matches (geanylatex, geanyvc).
Only geanylatex is left here. geanyVC is part since about 0.18.1
Sorry for the wrong information. I just had a look at the geany-plugins repository and there is still the geanyvc directory. Maybe this could be removed?
It is. Just check http://git.geany.org/geany-plugins/tree/
Cheers, Frank
On Sat, 22 Jan 2011 09:48:26 +0100, Frank Lanitz wrote:
On Thu, 20 Jan 2011 21:09:54 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 19 Jan 2011 21:25:54 +0100, Frank wrote:
On Wed, 19 Jan 2011 20:13:03 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 19 Jan 2011 19:26:02 +0100, Colomban wrote:
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?
0.20. I was never convinced maintaining plugins within g-p and outside
is a
good idea. AFAIK there are only a few plugins for which this
actually
matches (geanylatex, geanyvc).
Only geanylatex is left here. geanyVC is part since about 0.18.1
Sorry for the wrong information. I just had a look at the geany-plugins repository and there is still the geanyvc directory. Maybe this could be removed?
It is. Just check http://git.geany.org/geany-plugins/tree/
Then it seems the GIT mirror is broken. See http://geany-plugins.svn.sf.net/viewvc/geany-plugins/trunk, and for some reason, I think the SVN repo is more important than the GIT mirror :).
Regards, Enrico
On Sat, 22 Jan 2011 11:54:02 +0100, Enrico Tröger wrote:
On Sat, 22 Jan 2011 09:48:26 +0100, Frank Lanitz wrote:
On Thu, 20 Jan 2011 21:09:54 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 19 Jan 2011 21:25:54 +0100, Frank wrote:
On Wed, 19 Jan 2011 20:13:03 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 19 Jan 2011 19:26:02 +0100, Colomban wrote:
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?
0.20. I was never convinced maintaining plugins within g-p and outside
is a
good idea. AFAIK there are only a few plugins for which this
actually
matches (geanylatex, geanyvc).
Only geanylatex is left here. geanyVC is part since about 0.18.1
Sorry for the wrong information. I just had a look at the geany-plugins repository and there is still the geanyvc directory. Maybe this could be removed?
It is. Just check http://git.geany.org/geany-plugins/tree/
Then it seems the GIT mirror is broken. See http://geany-plugins.svn.sf.net/viewvc/geany-plugins/trunk, and for some reason, I think the SVN repo is more important than the GIT mirror :).
Ok, I see now it's gone :).
Regards, Enrico
Le 22/01/2011 11:54, Enrico Tröger a écrit :
On Sat, 22 Jan 2011 09:48:26 +0100, Frank Lanitz wrote:
On Thu, 20 Jan 2011 21:09:54 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 19 Jan 2011 21:25:54 +0100, Frank wrote:
On Wed, 19 Jan 2011 20:13:03 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 19 Jan 2011 19:26:02 +0100, Colomban wrote:
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?
0.20. I was never convinced maintaining plugins within g-p and outside is a good idea. AFAIK there are only a few plugins for which this actually matches (geanylatex, geanyvc).
Only geanylatex is left here. geanyVC is part since about 0.18.1
Sorry for the wrong information. I just had a look at the geany-plugins repository and there is still the geanyvc directory. Maybe this could be removed?
It is. Just check http://git.geany.org/geany-plugins/tree/
Then it seems the GIT mirror is broken. See http://geany-plugins.svn.sf.net/viewvc/geany-plugins/trunk, and for some reason, I think the SVN repo is more important than the GIT mirror :).
Seems that git-svn doesn't remove .svn directories, so the dirs containing them doesn't get removed...