geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: [DISCUSS] Geronimo Eclipse Plugin (GEP) questions
Date Wed, 24 Oct 2007 19:18:05 GMT

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

Mime
View raw message