OSGI does version ranges :)
Aaron Mulder wrote:
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
> 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 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
