geronimo-dev mailing list archives

So, it definetly doesn't warrent a major last minute rework to 1.1, but
it does worry me that we and our user community may waste a lot of time
creating plugins for 1.1, just to have to rerelease them for 1.1.1. If
we can come up with a patch for 1.1.1 that would allow plugins to
effectively say "I work on Geronimo 1.1*" or "I work on Geronimo 1.2*",
then I think we would have a solution that application and services
providers could really jump on and start using.
For 1.2, we definetly need to discuss this whole plugin feature and
agree on real user application and system upgrade scenarios, so we can
enhance/test/verify the current implementation to support as many
scenarios as possible along with providing much needed docs and tooling...
-Donald
Aaron Mulder wrote:
> Well, if you're going to submit that patch, you need to include a
> change in the annotation in the plugin schema along with it -- it
> specifically says that field is an exact match.
>
> I'm still not sure I'm on board with this, though. I don't feel like
> we can say with confidence that a plugin that works in 1.1 will work
> in all 1.1.x releases. Perhaps if we can articulate the rules for
> what changes are acceptable for 1.1, and that implies that plugins
> shouldn't break, then I'd feel more comfortable with this. We'd also
> have to release 1.1 as 1.1.0 so that if you *wanted* to limit it to
> the initial 1.1 release, you could.
>
> Thanks,
> Aaron
>
> On 6/8/06, Paul McMahan <paulmcmahan@gmail.com> 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
>>
>> Index:
>> modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
>>
>> ===================================================================
>> ---
>> modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
>> (revision
>> 412744)
>> +++
>> modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
>> (working
>> 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 <ammulder@alumni.princeton.edu> 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 <paulmcmahan@gmail.com> wrote:
>> > > On 6/8/06, Donald Woods <drw_web@yahoo.com> 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
>> > >
>> >
>>
>
>