As I see the only leftover from 2.0 you're talking about is generics, I would like to mention a few more. Back in may (when 1.3 was about to be released half of june), backporting of a few things from 2.0 has been postponed to a 1.4. As we had to backport our code from 2.0, I remember these: * alternate parents: in 2.0, there was a possibility to define an alternate parent to add child components. * markup fragments: in 1.3, calling renderComponent() (for Ajax requests) fails if no markup is associated with that component or the direct parent of that container. In 2.0, this was no problem (I suppose because of the way markup fragments were assigned to components)
Is there any chance that these get backported ? Jan. Eelco Hillenius 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 > > -- View this message in context: http://www.nabble.com/1.4-Wish-List-tp14349485p14370194.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
