geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shiva Kumar H R" <shiv...@gmail.com>
Subject Re: [DISCUSS] Geronimo Eclipse Plugin (GEP) questions
Date Thu, 25 Oct 2007 05:26:44 GMT
On 10/25/07, Kevan Miller <kevan.miller@gmail.com> 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

Mime
View raw message