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
