> i am fine with 1.4 being _just_ generics if after 1.4 comes out we > drop support for 1.3. otherwise it will be like what johan says: > > most bugs will affect 1.3 and 1.4 since they are the same code base > sans generics. after 1.4 comes out we have to start 1.5 immediately > because 1.4 will be a very short release (just generics). so the said > bug will most likely affect 1.5 as well. so now we have to merge the > fix into 1.3, 1.4, 1.5 <== 3 branches to maintain. sucks big time.
I think you guys have a different idea than I have. I was talking about 1.4.1 before doing 1.4.1. The idea is to quickly release 1.4.0, and then go on with 1.4.1 without supporting 1.4.0 as a separate branch. So for clarity, the focus for 1.4.0 is to get those last things of 2.0 in asap. That shouldn't be too hard, and once were done, we'll have a stable (because we didn't introduce too much new functionality) release that people will feel comfortable using. Then we start 1.4.1 and don't look back. > so if we drop support for 1.3 as soon as we branch 1.4 im fine with > 1.4 having just generics. We had that idea of dropping 1.3/ focussing on one release anyway. Dropping is too harsh though. We should EOL 1.2 (in fact we already did) and once we start on 1.4.x, we should only fix important things in 1.3.x for those who really can't go Java 5. My hunch is that by now, that group will be quite small, and since 1.4.0 will be backwards compatible (unless you're not using Java 5 and up), most people will be fine upgrading to 1.4.0 as if it were a minor release. So our plan of attack should be: * Focus on the missing 2.0 features for 1.4.0 (that's really only the generics, right?) and release just that. * We work on 1.4.x as if it were a minor release. The only real difference is going Java 5. That means that we don't maintain 1.3 separately except for urgent bugs/ people specifically requesting it (like we've done with 1.2) * After 1.4.0 is released, we can go on with 1.4.1. Some API breaks between 1.4.0 and 1.4.1 would be fine, but let's learn from our 2.0 debacle (which still bite me today, as I'm still fixing some of the last things in WIA!!!) and Tapestry's errors and try to keep those minimal. There are plenty of things that can be improved without overhauling the API again, and cosmetic improvements shouldn't be our priority anymore. Eelco
