geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: Version numbers for plugins of external apps
Date Mon, 03 Mar 2008 20:36:19 GMT
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
>>
>


Mime
View raw message