-1 to a branch per server release (like GEP 2.1.x only works with Server 2.1.x) as this would create a maintenance nightmare, where we would now have to fix a given bug or add a new feature (or upgrade to a newer Eclipse level) in 4 branches (1.1, 2.0, 2.1, 2.2) instead of just one.
For 3.0, we should really stop this backwards release support and start fresh, especially given all of the rework to move to OSGi and possible move from XMLBeans to JAXB.... That would leave us one 2.2.x branch for prior release support and a 3.x branch moving forward. -Donald On 3/3/10 10:46 AM, Rex Wang wrote: > > > 2010/3/3 Kevan Miller <kevan.mil...@gmail.com > <mailto:kevan.mil...@gmail.com>> > > > On Mar 3, 2010, at 12:58 AM, Delos wrote: > > > Hi all, > > > > Johannes suggested that GEP make release more frequently. The > reason is user may get new fixes earlier, instead of waiting for > next release together with Geronimo server. In this way, it will be > more convenient for GEP to provide new improvement, such as support > for eclipse of latest version. To support it, the version number of > GEP has to be redesigned. > > > > We need to add qualifier segment to the version number, such as > 2.2.0.0, 2.2.0.1 and 2.2.0.2. Then, for each release of Geronimo > server, GEP version will contains server version number as prefix > and qualifier segment as 0. For GEP release in future, the qualifier > of its version number will increase by 1 until server announce a new > release. For example, for Geronimo server 2.2.0, GEP version will be > 2.2.0.0; if GEP has to announce a new release after that, its > version will be 2.2.0.1. > > > > In general, GEP version will evolve as below > > 1) Version number of GEP will contain four digitals > > 2) If there is a G server release, GEP will announce a new release > for it. GEP version number is three digitals of server version > number suffixed with .0 > > 3) GEP may have several maintenance releases. Only last digital > increase by 1 for maintenance releases version number. > > > > Johannes, please correct me, if there is any mistake in my > description. > > > > Could you express your attitude toward Johannes' suggestion? > > Hi Delos, > More frequent releases would certainly be a good thing. I don't see > how anybody would object to that. > > Maybe I don't understand the issue (e.g. interdependencies between > GEP and G). However, to my knowledge, there's nothing that requires > GEP version numbers to stay exactly in sync with Geronimo server > releases. So, I'm not sure why 4 version numbers are a *hard* > requirement. So, GEP 2.2.x would indicate that it was built for a G > 2.2.y server. You just wouldn't know how 'x' compares to 'y'. But a > simple practice would be to get the latest GEP 2.2.x release. > > 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? > > > 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 ? > > 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.. > > -Rex > > > That said, if you, other GEP devs, and especially GEP users would > find this version scheme useful, then it sounds good to me. > > --kevan > > > > > -- > Lei Wang (Rex) > rwonly AT apache.org <http://apache.org>
