I agree with Kevan that we need to be practical here. Would 2.0 GEP
supports 2.0 level and all 2.0.X levels of geronimo?
Lin
Kevan Miller 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).
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...
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.
--kevan
