+1 on adding a forth digit, while maintaining existing 1.1-2.2 server support in the same GEP 2.2.x.x build, along with some wiki updates explaining which versions should be used for given server/Eclipse combinations.
-Donald On 3/5/10 3:30 AM, Delos wrote: > Hi, > > Hopefully, we can make a decision on this.-:) > > 2010/3/4 Delos <[email protected] <mailto:[email protected]>> > > 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 <[email protected] > <mailto:[email protected]>> > > > 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
