> a) focus on stabilizing 1.3 first, meanwhile keep supporting 2.0 > (though only for bugfixes). 1.4 will be the release with backports of > the currently missing 2.0 features, and 1.5 will be 1.4 + the Java 5 > features (including generics). > > b) as a) but rather than developing 1.3 up to a final release, freeze > asap (only fix bugs) and start on 1.4 > > c) put all backports except for the Java 5 features in 1.3 after the > beta1 release (which we agreed upon doing this weekend). 1.4 will be > for the Java 5 features, and the branch should be started as soon as > 1.3 is feature complete.
I feel very strongly about choosing c). Imo, a) takes too long for the people currently working on 2.0 (including myself for Wicket In Action). We basically tell them to hold their breath until we are ready for it, which in fact punishes them twice for being early adaptors (who I think we should value especially giving the type of framework Wicket is). I think b) would be good if it worked. However, I don't believe it will. We have been annoyingly slow in putting out releases this year. Sure there have been lots of reasons for it, but the fact remains that even though we plan to move fast with releases, we never actually do[1]. And with all the best intentions, I have absolutely not doubt that if we follow b), it'll be months up to a year before we reach 1.5. So for me c) is the best package. We'll have the pain (of which I doubt the intensity for most people, but let's play with Johan's branch for that) now, which probably sucks, but it is the quickest way to get things really stable. We will have implemented all the API changes we have been thinking about the last 1.5 years, and 1.3 will be a release that'll be good for a long time. We'll have a separate branch for Java 5 stuff with 1.4, but as long as we want to support Java 1.4, we'll have that anyway. The code should be largely the same except for the generified components and models and some 1.5 constructs. Compared to maintaining the current 2.0 and 1.3, that should be a piece of cake. A final argument for c) is that it just pushes us to get it over with. My 2c, Eelco [1] http://www.nabble.com/remove-add%28%29-and-pass-parent-in-constructor--tf929620.html The interesting thing there is that even back then there was discussion on whether to break early or not. I think in hind-sight we can say that it was a bad decision we didn't do it right away, which makes my opinion about c) even stronger. We might have been 'stuck' with the new constructor forever you may argue, but otoh, we might have found out it wasn't gonna work earlier. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
