(shifting towards a more appropriate subject)
On 21 Dec 2004, at 14:19, Henning P. Schmiedehausen wrote:
robert burrell donkin <[EMAIL PROTECTED]> writes:
On 21 Dec 2004, at 08:07, Henning P. Schmiedehausen wrote:
robert burrell donkin <[EMAIL PROTECTED]> writes:
the question i pose is: are we trying for a JCL 2.0 which in my mind would be a compatible evolution of JCL 1.0 aiming to solve all the major JCL 1.0 itches or are we aiming for a JCL 1.1 (better discover and factoring) plus additional pluggable modules...?
Personally, I'd like to aim for 1.1. These goals are already a good step on the way to 2.0 and also address most of the PITAs (PsITA?) that we currently have.
IMHO addressing all of richard's goals properly at once on a single
track would mean aiming for a 2.0 release. i wouldn't be happy shipping
a 1.1 based on the 1.0 code with the extras tacked on since many of the
existing issues will simply be magnified. JCL has numerous users and
critics so it's important that what we release is right.
by aiming for a 1.1 release i mean evolution and modularity as opposed to a big bang. as soon as the repository has been converted, we would start a release process for 1.0.5 (the work done to plug memory leaks with Brian Stansberry is important) and then implement the discovery revisions. JCL 1.1 should feature just the improved, modular discovery and it should be possible quickly to start a release process for that release. we may wish to consider adopting a release process more similar to struts and tomcat.
more modular discovery would allow the various parts of the proposal to
be progressed either separately or as a unit (as appears best) without
effecting the core. i suspect that the method tracing is more
controversial in design terms but easy to implement whereas there are a
lot of details about the i18n support which may need some work and
thought.
opinions?
Sounds good, I like it. Especially with a "brick" like JCL, which is used
under the hood in many places, it is important that we get this right.
i can pull some stuff together on the wiki if people are in agreement with this general approach.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
