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-----
