I'm not ok with dropping binary compatibility for 1.4.1. Why call it 1.4.1if it is in fact 1.5 or 2.0? I'd rather implement a milestone schedule for 1.4, like the Eclipse project does:
1.4-M1 – just generics/left overs from 2.0, bug fixes from 1.3 1.4-M2 – additional 1.5 features (mount annotations? varargs?), other stuff, bug fixes from 1.3 1.4-M3 – other stuff, bug fixes from 1.3 1.4-RC1 – bug fixes... 1.4-RC2 – bug fixes... 1.4-RC3 – bug fixes... 1.4 – final Martijn On Dec 15, 2007 7:31 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > are we ok with this? the policy so far has been that minor releases > are binary compatible, so we cant have api breaks between 1.4.0 and > 1.4.1 just for sake of adding new features... that is why i said after > 1.4.0 is out we would have to immediately start on 1.5.0.... > > -igor > > > On Dec 15, 2007 9:56 AM, Eelco Hillenius <[EMAIL PROTECTED]> > wrote: > > > 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 > > > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-rc1 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
