Delos, +1 for your proposal. -Jack
On Fri, Mar 5, 2010 at 4:30 PM, Delos <dait...@gmail.com> wrote: > Hi, > > Hopefully, we can make a decision on this.-:) > > 2010/3/4 Delos <dait...@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.mil...@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 >
