-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Jencks wrote, On 1/6/2006 11:10 AM: > Either I don't understand what is being proposed or I think it is a > recipe for disaster. > > My past experience with open source projects leads me to believe that > having more than one main development area that is leading to a release > is likely to cause only confusion, not progress towards functionality. > > In my opinion if we call head 2.0 and start adding JEE 5 features to > it, there will never be any more j2ee 1.4 releases with added > functionality. We will have a couple bug fix 1.0 releases, then a year > or so while we try to finish JEE 5. I don't think this is acceptable. > > I would like to propose a process by which disruptive new feature > development occurs in separate subprojects or feature-specific branches > that can be merged into trunk when feature complete and stable. > > I realize there are some significant problems with this as regards JEE > 5, at least as far as jdk support level, in that JEE 5 requires use of > jdk 1.4 incompatible code. Personally I don't have enough information > about how hard it is to convert to generics to begin to guess what > these problems might be. It would also be useful to know more about > e.g. whether retrotranslator might actually work. > > I think in order to consider this realistically we need a list of > features we plan to add and to decide for each one of them whether it > requires jdk 1.5 support and whether it can fit into "1.0". For > instance I think the proposed security improvements could fit into 1.0 > written in jdk 1.4. > > At this point, I think we should label head 1.1-SNAPSHOT and work on > any features that require 1.5 in one or more branches, labelled by > feature.
Your assumption is that 1.5 features are compact concise changes. The changes that are required, though, are quite comprehensive. I think we at least need a single 1.5 branch as well as a 1.4 branch. > I also think we need to decide on and publish criteria for including > bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just go > for 1.1. We need to pump out 1.0.1 ASAP. Regards, Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvsmc1xC6qnMLUpYRAjisAJ4uYVFdWnt8ZR4Ib/a6hAJgMsDBDgCdGZIc kpoS00XdIBMpN8z5Qsa3Ll4= =6bQl -----END PGP SIGNATURE-----
