David has a compelling argument...
I am concerned about delivering j2ee 1.4 features and release over
the next year while jee5 is written. I don't want to repeat the
lesson we all learned with the very very long gap between m3 and m4.
With out micro kernel design, don't you think we should be able to
develop most of the jee5 new features in plugin modules or subprojects?
Regaurdless, I have a few features I'd like to put into 1.x to make
transition to 2.x painless, so I will be working on whatever branch
is to become 1.1.
-dain
On Jan 6, 2006, at 11:10 AM, David Jencks 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-----
