Once I finish the suddenly-urgent mountain of book work, I have a lot more console and management stuff to work on. There's no reason that has to wait for a rewritten CORBA stack, EJB3 container, security stack, etc., much less all the new specs and JSRs. So I certainly plan to contribute to a 1.1 release. (I'm not sure whether new Jetspeed/Pluto integration would fit into 1.1 or 2.0, though 1.1 would be nice.)
I'd prefer to see us draw up as much of a feature list as we can for 1.1 and 2.0, and then based on those think about where we want to put things and how we branch. That may also suggest a time frame for each. Aaron On 1/6/06, David Jencks <[EMAIL PROTECTED]> wrote: > 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. > > 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. > > thanks > david jencks > > > > On Jan 6, 2006, at 9:10 AM, Alan D. Cabrera wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Matt Hogstrom wrote, On 1/6/2006 7:07 AM: > >> I'll summarize what I think I read. > >> > >> HEAD will be 2.0 which includes JEE 5 and other significant work > >> (Maven > >> 2 conversion, etc.) > >> > >> Branches/1.0 will be where the work for 1.0.x will take place. It > >> would > >> be from this code base we'd branch to a 1.1 when appropriate. > > > > So, we would eventually have 2 branches and 1 trunk: > > > > branches/1.0 > > branches/1_trunk > > tags/* > > trunk > > > >> I'm updating my local copy of the branches/1.0 with a version > >> change for > >> Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and > >> Jetty 5.1.10 to incoroporate the latent fixes. > >> > >> I'll build and test to make sure its still working (I'm not going > >> to run > >> TCK). and then commit these changes back when I've confirmed we're > >> ready > >> to go for 1.0.1. Does this sound workable? > > > > Can we have jira issues assigned to 1.0.1 so that we can see what's > > coming down the pipeline? > > > > > > Regards, > > Alan > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.2 (MingW32) > > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > > > iD8DBQFDvqSa1xC6qnMLUpYRArhpAJ91d5cSrHGEsY0pG6Jf+Nb+9gNuSgCfR8gH > > m3qYJWEG9Zej/Sg+O5pMPQA= > > =goh1 > > -----END PGP SIGNATURE----- > > > >
