Re: Plugin versioning problems

[Donald Woods]

Paul, what if we tweaked your proposed patch and allowed the plugin to provide an optional attribute of exactVersion=required, which would control the behavior?

-Donald

Paul McMahan wrote:

I definitely agree that a full fledged solution for version ranges is
out of scope for G 1.1.x.  I was thinking that a minor change to the
plugin installer's version checking could at least partially address
Donald's concerns and also avoid the version mismatch problem Dave C.
found in the candidate build.  Here's a patch that makes the plugin
installer only check the digits of geronimo's version that the
plugin's xml specifies.  So if the plugin specifies
<geronimo-version>1.1</geronimo-version> then it can be installed into
1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...

Best wishes,
Paul


===================================================================

412744)

copy)
@@ -1409,7 +1409,7 @@
            if(gerVersion == null || gerVersion.equals("")) {
                throw new IllegalStateException("geronimo-version
should not be empty!");
            }
-            if(gerVersion.equals(version)) {
+            if(version.startsWith(gerVersion)) {
                match = true;
                break;
            }


On 6/8/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:

Index: modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java --- modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java (revision +++ modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java (working

Perhaps I was unclear; I didn't mean to say this was a bad idea, only
that our code doesn't currently support it.  I expect version ranges
are on the road map, but if you want to work on them, you're more than
welcome to.  :)

I don't think this is a G 1.1.x discussion, since AFAIK it would
require kernel changes.

Thanks,
     Aaron

On 6/8/06, Paul McMahan <[EMAIL PROTECTED]> wrote:
> On 6/8/06, Donald Woods <[EMAIL PROTECTED]> wrote:
> > 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

> > I should be able to specify 1.1 in the plugin and have it work on

>
> +1   This approach is similar to how eclipse plugin versioning works.
>
> From http://www.eclipse.org/equinox/documents/plugin-versioning.html :
> "How to specify plug-in requirements
> Plug-ins that require other plug-ins must qualify their requirements
> with a version range since the absence of a version range means that
> any version can satisfy the dependency. Given that all the changes
> between the version x.0.0 and the version x+1.0.0 excluded must be
> compatible (given the previous guidelines); the recommended range
> includes the minimal required version up-to but not including the next
> major release."
>
> IMHO geronimo should adopt eclipse's strategy for plugin versioning
> where possible since the two sets of base requirements are quite
> similar and eclipse is a few years ahead in this area.  The document
> referenced above spells out their  strategy in detail.
>
> Best wishes,
> Paul
>

> > behavior of 1.1-<starting with any alpha> is less than 1.1. Basically, > > 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.

smime.p7s
Description: S/MIME Cryptographic Signature