geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Version numbers for plugins of external apps
Date Tue, 04 Mar 2008 02:04:09 GMT
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.

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

View raw message