geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Delos <>
Subject Re: [DISCUSSION] Release GEP more frequently
Date Thu, 04 Mar 2010 05:04:56 GMT
Thanks for  your comments! Seems no objection for more frequent releases
till now, but there still some advices about implementation details.Here are
my answers to some of your questions.

*1) (Kevan) I will note that this proposal doesn't work too well for users
of previous versions of the Geronimo server. What versions of G 2.1.x would
a GEP 2.2.y.z correspond to? Or are you suggesting that G 2.1 users should
use a GEP 2.1.x adapter?*
In fact, the problems always exist. Until now, users of G server 2.1.x have
two choices, one is 2.1.x adapter and another is 2.2.x adapter. I recommend
user to use GEP 2.1.x adapter, because the server dependencies of GEP is in
same version as server. I think we may have another discussion about this
problem, since it's not brought by the suggestion.

*2)About the forth digit *
Just as Donald said, the best practice of forth digit for a single eclipse
plugin and feature is in format as *a_vDate*, for example, But it's only for single plugin or feature. As I
know, a product of eclipse plugins is never in format like this. Take WTP
for example, you may see date suffix in its plugins and features, but we
always say WTP 3.2.0 instead of WTP 3.2.0_v20100302.  Anyway, I strongly
agree the features and plugins in GEP adopt version number like this. But
the version number for whole GEP won't contains the date suffix.

*3) About backward compatibility*
v1.1 adapter is added in GEP 2.2 due to this JIRA think it's a
special case for GEP.
IMO, GEP should only contains adapters for servers which are still improved
by Geronimo community. Because both 2.1.x branch and 2.2.x branch of G
server are active, I agree GEP 3.0 contains adapters for v2.1 and v2.2. In
future, if any version of G server isn't supported any more, we may remove
its adapter from GEP.

Any other comments? To avoid any surprise in future release, I hope more PMC
members can get involved in this thread.-:)

2010/3/4 Kevan Miller <>

> On Mar 3, 2010, at 10:46 AM, Rex Wang wrote:
> IIRC, current approach is any GEP 2.2.* has the ability to support server
> 2.1.*,  2.0.*, even 1.1.*
> However, I do not think it is a best practice, because as the increase of
> server's version number, GEP might become more and more overstaffed.. and it
> is hard to tell at which time point the lower version server is out of
> service in the latest GEP. Also, for instance, if there is a new G 2.1.x
> release, which version of GEP shall we update to support it, the GEP2.2.y or
> GEP2.1.z or Both ?
> Right. Would have to hunt through the archives. At one point we had dropped
> 1.1 support in GEP (IIRC), but then it was added back in. Tim would remember
> better than I.
> I think the main advantage of staying the version numbers in sync with
> server is that it makes user very clear to know which GEP can work with a
> certain server. However, if we adopt this and make release more frequently,
> we should maintenance GEP in different branch. That is, GEP
> 2.2.x.201012345678 only support all the 2.2.y server(where y<=x), and not
> support 2.1.*, 1.1,*, so that if you try add a new server runtime in
> eclipse, you won't see a pretty long list that contains all Geronimo server
> versions..
> I think we need to support at least one back-level version of the server.
> Personally, I would like for GEP 3.0 to support 2.2 and 2.1, at least. But
> that's just me. I confess that I'm not in touch with the complexities this
> might introduce into GEP.
> --kevan

Best Regards,


View raw message