You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2008/03/02 02:18:40 UTC
Version numbers for plugins of external apps
How are we going to name plugins for external apps, such as roller or
apache directory?
There are three versions involved:
1. geronimo version
2. external app version
3. plugin version
I figure if we're developing/releasing it the groupId is going to be
o.a.g.plugins
That leaves us with the artifactId and version to possibly encode
this info into.
Lets assume a version number of x.y.z.
Here are some possibilities:
A. Don't encode anything, just have the plugin version be (3). So,
roller-jetty-1.0 would happen to be for roller 4.0 and geronimo 2.1,
and you'd have to look inside to find that out. I'd suggest in this
case that changes in roller or geronimo versions would bump the major
version x or minor version y whereas releasing an enhanced plugin for
the same app and geronimo versions would bump z.
B. Include the external app version in the artifactId and don't
encode the geronimo version. E.g., roller-4.0-jetty-1.0 would happen
to be for geronimo 2.1 but you could see that it's for roller 4.0
from the artifactId. This is basically the solution we used for
specs. I assume changing geronimo version would bump the major
version x or minor version y whereas releasing an enhanced plugin for
the same app and geronimo versions would bump z.
C. Include both the external app version and geronimo version in the
artifactId, e.g. roller-4.0-g-2.1-jetty-1.0 would be the first
release of a roller plugin using roller 4.0 and geronimo 2.1.
D. Include the geronimo version but not the external app version,
e.g. roller-g-2.1-jetty-1.0.
I'm inclined to go for (A) but see arguments for everything except D.
Thoughts?
thanks
david jencks
Re: Version numbers for plugins of external apps
Posted by Kevan Miller <ke...@gmail.com>.
On Mar 1, 2008, at 8:18 PM, David Jencks wrote:
> How are we going to name plugins for external apps, such as roller
> or apache directory?
>
> There are three versions involved:
> 1. geronimo version
> 2. external app version
> 3. plugin version
>
> I figure if we're developing/releasing it the groupId is going to be
> o.a.g.plugins
>
> That leaves us with the artifactId and version to possibly encode
> this info into.
>
> Lets assume a version number of x.y.z.
>
> Here are some possibilities:
>
> A. Don't encode anything, just have the plugin version be (3). So,
> roller-jetty-1.0 would happen to be for roller 4.0 and geronimo 2.1,
> and you'd have to look inside to find that out. I'd suggest in this
> case that changes in roller or geronimo versions would bump the
> major version x or minor version y whereas releasing an enhanced
> plugin for the same app and geronimo versions would bump z.
>
> B. Include the external app version in the artifactId and don't
> encode the geronimo version. E.g., roller-4.0-jetty-1.0 would
> happen to be for geronimo 2.1 but you could see that it's for roller
> 4.0 from the artifactId. This is basically the solution we used for
> specs. I assume changing geronimo version would bump the major
> version x or minor version y whereas releasing an enhanced plugin
> for the same app and geronimo versions would bump z.
>
> C. Include both the external app version and geronimo version in the
> artifactId, e.g. roller-4.0-g-2.1-jetty-1.0 would be the first
> release of a roller plugin using roller 4.0 and geronimo 2.1.
>
> D. Include the geronimo version but not the external app version,
> e.g. roller-g-2.1-jetty-1.0.
>
> I'm inclined to go for (A) but see arguments for everything except D.
>
> Thoughts?
Personally, I favor (A). Simple and I think it will work just fine
for most/all projects. I won't really have a problem if a more
explicit scheme (e.g. (C) is preferred by the group).
--kevan
Re: Version numbers for plugins of external apps
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I prefer A. Although I'm all for making things easier for a user I
think they should be choosing a plugin after doing some research and I
would hope that the documentation that led them to the plugin would
have outline the requirements. Also, when we ge to the point where a
plugin might actually tolerate more than one release we won't be
inclined to release new plugins with a version change where there is
no code change.
On Mar 1, 2008, at 8:18 PM, David Jencks wrote:
>
>
> A. Don't encode anything, just have the plugin version be (3). So,
> roller-jetty-1.0 would happen to be for roller 4.0 and geronimo 2.1,
> and you'd have to look inside to find that out. I'd suggest in this
> case that changes in roller or geronimo versions would bump the
> major version x or minor version y whereas releasing an enhanced
> plugin for the same app and geronimo versions would bump z.
Re: Version numbers for plugins of external apps
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Sat, Mar 1, 2008 at 5:18 PM, David Jencks <da...@yahoo.com> wrote:
> C. Include both the external app version and geronimo version in the
> artifactId, e.g. roller-4.0-g-2.1-jetty-1.0 would be the first
> release of a roller plugin using roller 4.0 and geronimo 2.1.
That's the longest versioning scheme, but I'm leaning towards this as
it can help easily differentiate between different versions of
respective artifacts a plugin works with. It made me thinking about
the same plugin, but for different Geronimo releases? As of now, we've
got 2.1 and 2.0.2. How would we express with the versioning scheme
that a given plugin works with 2.1 and 2.0.2 (if at all possible due
to different plugin descriptors).
I'm for C. If that doesn't work, we'll change/augment it.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Version numbers for plugins of external apps
Posted by Jason Warner <ja...@gmail.com>.
I'm leaning to either A or C. A seems neater and less confusing to a user,
but it requires more effort to learn what you're actually dealing with. C
makes all that version information readily available and is very handy to
have, but all those version numbers in one identifier can be confusing.
Plus, with C, where do you stop listing version numbers? What all do you
list in the identifier. What if you have a plugin that incorporates
multiple artifacts. The identifier could end up being pretty long if you're
listing all of them. I don't have any specific examples in mind. Does
anyone know of a current plugin where this might be the case?
On Mon, Mar 3, 2008 at 9:49 AM, Joe Bohn <jo...@earthlink.net> wrote:
> David Jencks wrote:
> > How are we going to name plugins for external apps, such as roller or
> > apache directory?
> >
> > There are three versions involved:
> > 1. geronimo version
> > 2. external app version
> > 3. plugin version
> >
> > I figure if we're developing/releasing it the groupId is going to be
> > o.a.g.plugins
> >
> > That leaves us with the artifactId and version to possibly encode this
> > info into.
> >
> > Lets assume a version number of x.y.z.
> >
> > Here are some possibilities:
> >
> > A. Don't encode anything, just have the plugin version be (3). So,
> > roller-jetty-1.0 would happen to be for roller 4.0 and geronimo 2.1, and
> > you'd have to look inside to find that out. I'd suggest in this case
> > that changes in roller or geronimo versions would bump the major version
> > x or minor version y whereas releasing an enhanced plugin for the same
> > app and geronimo versions would bump z.
> >
> > B. Include the external app version in the artifactId and don't encode
> > the geronimo version. E.g., roller-4.0-jetty-1.0 would happen to be for
> > geronimo 2.1 but you could see that it's for roller 4.0 from the
> > artifactId. This is basically the solution we used for specs. I assume
> > changing geronimo version would bump the major version x or minor
> > version y whereas releasing an enhanced plugin for the same app and
> > geronimo versions would bump z.
> >
> > C. Include both the external app version and geronimo version in the
> > artifactId, e.g. roller-4.0-g-2.1-jetty-1.0 would be the first release
> > of a roller plugin using roller 4.0 and geronimo 2.1.
> >
> > D. Include the geronimo version but not the external app version, e.g.
> > roller-g-2.1-jetty-1.0.
> >
> > I'm inclined to go for (A) but see arguments for everything except D.
> >
> > Thoughts?
>
> I like (C) because you can easily determine everything from the plugin
> name and I think that is the most helpful for a user. Yes, it's long
> and ugly ... and you could figure out the other versions in other ways
> ... but it's very helpful. We could eliminate one more character by
> compressing g-2.1 to g2.1.
>
> Joe
>
>
>
--
~Jason Warner
Re: Version numbers for plugins of external apps
Posted by Joe Bohn <jo...@earthlink.net>.
David Jencks wrote:
> How are we going to name plugins for external apps, such as roller or
> apache directory?
>
> There are three versions involved:
> 1. geronimo version
> 2. external app version
> 3. plugin version
>
> I figure if we're developing/releasing it the groupId is going to be
> o.a.g.plugins
>
> That leaves us with the artifactId and version to possibly encode this
> info into.
>
> Lets assume a version number of x.y.z.
>
> Here are some possibilities:
>
> A. Don't encode anything, just have the plugin version be (3). So,
> roller-jetty-1.0 would happen to be for roller 4.0 and geronimo 2.1, and
> you'd have to look inside to find that out. I'd suggest in this case
> that changes in roller or geronimo versions would bump the major version
> x or minor version y whereas releasing an enhanced plugin for the same
> app and geronimo versions would bump z.
>
> B. Include the external app version in the artifactId and don't encode
> the geronimo version. E.g., roller-4.0-jetty-1.0 would happen to be for
> geronimo 2.1 but you could see that it's for roller 4.0 from the
> artifactId. This is basically the solution we used for specs. I assume
> changing geronimo version would bump the major version x or minor
> version y whereas releasing an enhanced plugin for the same app and
> geronimo versions would bump z.
>
> C. Include both the external app version and geronimo version in the
> artifactId, e.g. roller-4.0-g-2.1-jetty-1.0 would be the first release
> of a roller plugin using roller 4.0 and geronimo 2.1.
>
> D. Include the geronimo version but not the external app version, e.g.
> roller-g-2.1-jetty-1.0.
>
> I'm inclined to go for (A) but see arguments for everything except D.
>
> Thoughts?
I like (C) because you can easily determine everything from the plugin
name and I think that is the most helpful for a user. Yes, it's long
and ugly ... and you could figure out the other versions in other ways
... but it's very helpful. We could eliminate one more character by
compressing g-2.1 to g2.1.
Joe
Re: Version numbers for plugins of external apps
Posted by Jarek Gawor <jg...@gmail.com>.
I'm for A. The geronimo version and external app version are already
provided in the plugin descriptor so no need to duplicate this info in
the plugin version.
Jarek
On Sat, Mar 1, 2008 at 8:18 PM, David Jencks <da...@yahoo.com> wrote:
> How are we going to name plugins for external apps, such as roller or
> apache directory?
>
> There are three versions involved:
> 1. geronimo version
> 2. external app version
> 3. plugin version
>
> I figure if we're developing/releasing it the groupId is going to be
> o.a.g.plugins
>
> That leaves us with the artifactId and version to possibly encode
> this info into.
>
> Lets assume a version number of x.y.z.
>
> Here are some possibilities:
>
> A. Don't encode anything, just have the plugin version be (3). So,
> roller-jetty-1.0 would happen to be for roller 4.0 and geronimo 2.1,
> and you'd have to look inside to find that out. I'd suggest in this
> case that changes in roller or geronimo versions would bump the major
> version x or minor version y whereas releasing an enhanced plugin for
> the same app and geronimo versions would bump z.
>
> B. Include the external app version in the artifactId and don't
> encode the geronimo version. E.g., roller-4.0-jetty-1.0 would happen
> to be for geronimo 2.1 but you could see that it's for roller 4.0
> from the artifactId. This is basically the solution we used for
> specs. I assume changing geronimo version would bump the major
> version x or minor version y whereas releasing an enhanced plugin for
> the same app and geronimo versions would bump z.
>
> C. Include both the external app version and geronimo version in the
> artifactId, e.g. roller-4.0-g-2.1-jetty-1.0 would be the first
> release of a roller plugin using roller 4.0 and geronimo 2.1.
>
> D. Include the geronimo version but not the external app version,
> e.g. roller-g-2.1-jetty-1.0.
>
> I'm inclined to go for (A) but see arguments for everything except D.
>
> Thoughts?
>
> thanks
> david jencks
>
>
Re: Version numbers for plugins of external apps
Posted by David Jencks <da...@yahoo.com>.
I thought about this some more and think that I am firmly in favor of A.
1. anything else is going to result in changing the directory name of
the plugin build project using svn cp foo-1.1 foo-1.2 or svn mv
foo-1.1 foo-1.2 when either the source project or geronimo version
changes. This is just weird.
2. We should work on making sure the plugin catalog and its viewers
can easily show what the dependencies are rather than overloading the
maven artifactId
3. It's entirely possible that a plugin can work with multiple
versions of source project and geronimo. This won't be the case with
jee source projects since a significant amount of code/info gets
copied into the plugin, but for other plugins this is apt to be a
significant factor.
thanks
david jencks
On Mar 3, 2008, at 12:36 PM, Gianny Damour wrote:
> Maybe I should have said before why I'm inclined to go for B then C
> in this order: My understanding is that by convention the geronimo
> version is encoded in the plugin repository URI. So, when a user
> browses the plugins within a repository, he already does know which
> Geronimo version is targeted.
>
> Thanks,
> Gianny
>
> On 02/03/2008, at 6:54 PM, Gianny Damour wrote:
>
>> Hi,
>>
>> I believe the external app version is quite important from an end-
>> user perspective; so, I'm inclined to go for B then C. For
>> instance, users clearly see the external app version while
>> browsing plugin repositories. Furthermore, this allows the clear
>> versioning of two plugins for distinct external application versions.
>>
>> Thanks,
>> Gianny
>>
>> On 02/03/2008, at 12:18 PM, David Jencks wrote:
>>
>>> How are we going to name plugins for external apps, such as
>>> roller or apache directory?
>>>
>>> There are three versions involved:
>>> 1. geronimo version
>>> 2. external app version
>>> 3. plugin version
>>>
>>> I figure if we're developing/releasing it the groupId is going to
>>> be o.a.g.plugins
>>>
>>> That leaves us with the artifactId and version to possibly encode
>>> this info into.
>>>
>>> Lets assume a version number of x.y.z.
>>>
>>> Here are some possibilities:
>>>
>>> A. Don't encode anything, just have the plugin version be (3).
>>> So, roller-jetty-1.0 would happen to be for roller 4.0 and
>>> geronimo 2.1, and you'd have to look inside to find that out.
>>> I'd suggest in this case that changes in roller or geronimo
>>> versions would bump the major version x or minor version y
>>> whereas releasing an enhanced plugin for the same app and
>>> geronimo versions would bump z.
>>>
>>> B. Include the external app version in the artifactId and don't
>>> encode the geronimo version. E.g., roller-4.0-jetty-1.0 would
>>> happen to be for geronimo 2.1 but you could see that it's for
>>> roller 4.0 from the artifactId. This is basically the solution
>>> we used for specs. I assume changing geronimo version would bump
>>> the major version x or minor version y whereas releasing an
>>> enhanced plugin for the same app and geronimo versions would bump z.
>>>
>>> C. Include both the external app version and geronimo version in
>>> the artifactId, e.g. roller-4.0-g-2.1-jetty-1.0 would be the
>>> first release of a roller plugin using roller 4.0 and geronimo 2.1.
>>>
>>> D. Include the geronimo version but not the external app version,
>>> e.g. roller-g-2.1-jetty-1.0.
>>>
>>> I'm inclined to go for (A) but see arguments for everything
>>> except D.
>>>
>>> Thoughts?
>>>
>>> thanks
>>> david jencks
>>>
>>
>
Re: Version numbers for plugins of external apps
Posted by Gianny Damour <gi...@optusnet.com.au>.
Maybe I should have said before why I'm inclined to go for B then C
in this order: My understanding is that by convention the geronimo
version is encoded in the plugin repository URI. So, when a user
browses the plugins within a repository, he already does know which
Geronimo version is targeted.
Thanks,
Gianny
On 02/03/2008, at 6:54 PM, Gianny Damour wrote:
> Hi,
>
> I believe the external app version is quite important from an end-
> user perspective; so, I'm inclined to go for B then C. For
> instance, users clearly see the external app version while browsing
> plugin repositories. Furthermore, this allows the clear versioning
> of two plugins for distinct external application versions.
>
> Thanks,
> Gianny
>
> On 02/03/2008, at 12:18 PM, David Jencks wrote:
>
>> How are we going to name plugins for external apps, such as roller
>> or apache directory?
>>
>> There are three versions involved:
>> 1. geronimo version
>> 2. external app version
>> 3. plugin version
>>
>> I figure if we're developing/releasing it the groupId is going to
>> be o.a.g.plugins
>>
>> That leaves us with the artifactId and version to possibly encode
>> this info into.
>>
>> Lets assume a version number of x.y.z.
>>
>> Here are some possibilities:
>>
>> A. Don't encode anything, just have the plugin version be (3).
>> So, roller-jetty-1.0 would happen to be for roller 4.0 and
>> geronimo 2.1, and you'd have to look inside to find that out. I'd
>> suggest in this case that changes in roller or geronimo versions
>> would bump the major version x or minor version y whereas
>> releasing an enhanced plugin for the same app and geronimo
>> versions would bump z.
>>
>> B. Include the external app version in the artifactId and don't
>> encode the geronimo version. E.g., roller-4.0-jetty-1.0 would
>> happen to be for geronimo 2.1 but you could see that it's for
>> roller 4.0 from the artifactId. This is basically the solution we
>> used for specs. I assume changing geronimo version would bump the
>> major version x or minor version y whereas releasing an enhanced
>> plugin for the same app and geronimo versions would bump z.
>>
>> C. Include both the external app version and geronimo version in
>> the artifactId, e.g. roller-4.0-g-2.1-jetty-1.0 would be the
>> first release of a roller plugin using roller 4.0 and geronimo 2.1.
>>
>> D. Include the geronimo version but not the external app version,
>> e.g. roller-g-2.1-jetty-1.0.
>>
>> I'm inclined to go for (A) but see arguments for everything except D.
>>
>> Thoughts?
>>
>> thanks
>> david jencks
>>
>
Re: Version numbers for plugins of external apps
Posted by Gianny Damour <gi...@optusnet.com.au>.
Hi,
I believe the external app version is quite important from an end-
user perspective; so, I'm inclined to go for B then C. For instance,
users clearly see the external app version while browsing plugin
repositories. Furthermore, this allows the clear versioning of two
plugins for distinct external application versions.
Thanks,
Gianny
On 02/03/2008, at 12:18 PM, David Jencks wrote:
> How are we going to name plugins for external apps, such as roller
> or apache directory?
>
> There are three versions involved:
> 1. geronimo version
> 2. external app version
> 3. plugin version
>
> I figure if we're developing/releasing it the groupId is going to
> be o.a.g.plugins
>
> That leaves us with the artifactId and version to possibly encode
> this info into.
>
> Lets assume a version number of x.y.z.
>
> Here are some possibilities:
>
> A. Don't encode anything, just have the plugin version be (3).
> So, roller-jetty-1.0 would happen to be for roller 4.0 and geronimo
> 2.1, and you'd have to look inside to find that out. I'd suggest
> in this case that changes in roller or geronimo versions would bump
> the major version x or minor version y whereas releasing an
> enhanced plugin for the same app and geronimo versions would bump z.
>
> B. Include the external app version in the artifactId and don't
> encode the geronimo version. E.g., roller-4.0-jetty-1.0 would
> happen to be for geronimo 2.1 but you could see that it's for
> roller 4.0 from the artifactId. This is basically the solution we
> used for specs. I assume changing geronimo version would bump the
> major version x or minor version y whereas releasing an enhanced
> plugin for the same app and geronimo versions would bump z.
>
> C. Include both the external app version and geronimo version in
> the artifactId, e.g. roller-4.0-g-2.1-jetty-1.0 would be the first
> release of a roller plugin using roller 4.0 and geronimo 2.1.
>
> D. Include the geronimo version but not the external app version,
> e.g. roller-g-2.1-jetty-1.0.
>
> I'm inclined to go for (A) but see arguments for everything except D.
>
> Thoughts?
>
> thanks
> david jencks
>