geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <drw_...@yahoo.com>
Subject Re: Plugin versioning problems
Date Thu, 08 Jun 2006 12:25:32 GMT
What I meant by 1.1.* was the Maven behavior of private builds like 
1.1-1 being taken as newer than 1.1.  Also, being able to use the 
behavior of 1.1-<starting with any alpha> is less than 1.1.  Basically, 
I should be able to specify 1.1 in the plugin and have it work on 
1.1-SNAPSHOT and 1.1.1.  If a plugin worked on 1.1 but doesn't on 1.1.1, 
then I'd argue that we broke something in 1.1.1, given it should only be 
a maintenance release and app/plan breaking changes should only go into 1.2.

BTW - How can we add new Plugins to the geronimoplugins website?  Are we 
going to setup a Geronimo subproject (like Daytrader) with the site 
framework checked into svn, along with any scripts needed to build the 
plugins?  It seems convoluted to have samples and plugin builds in the 
main Geronimo tree, which are not shipped with the server or 
automatically pushed to geronimoplugins.  Wouldn't it be easier to 
maintain if we moved all the samples out to /trunk/samples/modules and 
all the equivalent plugin configs to /trunk/samples/plugins?  That way, 
the Samples and plugins can be built, published and enhanced separate 
from the server development....

-Donald


Aaron Mulder wrote:
> On 6/7/06, Donald Woods <drw_web@yahoo.com> wrote:
> 
>> Why shouldn't the Plugin support be as robust as module dependencies and
>> allow the user providing the plugin to decide if they can support
>> geronimo_version=*, 1.* or 1.1* ?  Limiting the plugins to only support
>> predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to
>> me and doesn't follow previous email threads about not deviating from
>> Maven2 versioning behavior...
> 
> 
> But what you've said here is "why shouldn't the plugin support be as
> robust as A and allow B" where A != B.  Module dependencies let you
> specify an exact version or no version.  Plugin dependencies also let
> you specify an exact version or no version.  Neither of these support
> 1.* or 1.1*.
> 
>> Just as with the Tomcat JSP/Servlet Examples, you could easily provide a
>> Plugin which should work on all 1.x releases....
> 
> 
> My preference it to opt-in supported version, not opt-out unsupported
> versions.  So I'd like the plugin developer to try a plugin on a
> Geronimo version and if it works, list that version as supported.  The
> alternative will most likely lead to Geronimo being willing to install
> a plugin but the plugin not working.  If we get fancier version
> dependencies we can consider things like "1.1.*" but I'm not sure I
> like that.  I'm willing to be convinced, but I'd want to hear from
> more plugin developers/maintainers.
> 
> Thanks,
>    Aaron
> 
> 

Mime
View raw message