geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jack Cai <greensi...@gmail.com>
Subject Re: [DISCUSSION] Release GEP more frequently
Date Fri, 05 Mar 2010 10:32:21 GMT
Delos, +1 for your proposal.

-Jack

On Fri, Mar 5, 2010 at 4:30 PM, Delos <daition@gmail.com> wrote:

> 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