On 10/25/07, Kevan Miller <[EMAIL PROTECTED]> wrote: > > > On Oct 23, 2007, at 9:08 PM, Tim McConnell wrote: > > > Hi everyone, I have a couple questions I'd like to discuss about > > the Geronimo Eclipse plugin: > > > > 1. How many versions of the Geronimo server should we continue to > > simultaneously support in the Geronimo Eclipse plugin ?? > > 2. What level of support should we provide in the Eclipse plugin > > for the Geronimo 1.2 Beta ?? > > > > My thoughts and/or opinions are as follows (simply to start the > > discussions): > > > > 1. The plugin now has support for four Geronimo releases (i.e., 1, > > 1.1.1, 1.2, and 2.0). I would like to support only three versions > > at a time. This would still allow an upward migration path for > > people who want to migrate their projects from older to new > > versions (which is apparently one of the major reasons for > > providing support for multiple versions to begin with). I feel > > though that support for only three versions at a time would > > facilitate a more stable (and smaller) code base, it would mitigate > > some of the test scenario permutations inherit with multiple > > version support, and ease the implementation transitions from one > > release of the GEP to another. We've had and continue to have > > difficulties supporting the Geronimo 2.0.2 deployment plans in the > > GEP, which I'm confident will finally be rectified in the next > > maintenance release of the GEP, but it's only exacerbated by > > supporting so many versions. > > Can you define what you mean by "version"? Currently we have a > major.minor[.service-level] release number scheme. By "release" do > you mean major number (e.g "2.0") or minor number (e.g. 2.0.1 and > 2.0.2) releases? > > Personally, I think it's just fine to support only one back-level > major.minor release (N-1) and the current major.minor releases (N). > Using a 2.1 release as a hypothetical example. IMO, the GEP could > support 2.1, and 2.0. Using the same methodology, a 2.0.2 GEP release > would support 2.0 and 1.1 (I see no reason to support 1.0 at this > point).
+1 I think we'd want to be practical, here. Time between releases may be > a factor. Also, usage should be a factor in deciding what releases to > support. We currently expect our users to migrate to G 2.0.x. We > don't plan on any new 1.1.x releases. This may change over time. If a > large number of users are on a back-level release, we may want to > maintain support for the back-level release, even if it would violate > the precedence we're defining here... +1 > > > 2. I would like to start to untangle some of the interdependencies > > we now have with the various features in the plugin in the upcoming > > GEP maintenance release. I know very little about the Geronimo 1.2 > > Beta, but I get the sense that it is more of a "one-off" rather > > than a nature progression from 1.1.1 to 2.0.x, and I just wonder > > though how much the 1.2 support in the plugin is really being used. > > If it's not being used, I would actually like to remove the 1.2 > > Beta code from the plugin in the upcoming maintenance release for > > the reasons I've mentioned above. > > I wouldn't characterize 1.2 as a "one-off", it was a natural > progression from 1.1 to 2.0. We ran into some bugs preparing for a > 1.2 release. Since most of our focus was on a 2.0 release, the 1.2 > issues never got resolved. At this point, I don't expect that we'll > have a "1.2" release. I think you can skip 1.2-beta. +1 --kevan > -- Thanks, Shiva Come to OS Summit Asia 2007 and learn about "Java EE 5 App Development on Geronimo 2.0 simplified using Eclipse" http://www.ossummit.com/2007/program/talk/16
