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
