geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Delos <dait...@gmail.com>
Subject Re: [DISCUSSION] Release GEP more frequently
Date Fri, 05 Mar 2010 08:30:17 GMT
Hi,

Hopefully, we can make a decision on this.-:)

2010/3/4 Delos <daition@gmail.com>

> 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,
> 2.2.0.1_v201003032010. 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
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-578.I 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 <kevan.miller@gmail.com>
>
>
>> 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,
>
> Delos
>



-- 
Best Regards,

Delos

Mime
View raw message