geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: Plugin versioning problems
Date Thu, 08 Jun 2006 13:16:50 GMT
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.


On 6/8/06, Paul McMahan <> wrote:
> On 6/8/06, Donald Woods <> 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
> > 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.
> +1   This approach is similar to how eclipse plugin versioning works.
> From :
> "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

View raw message