geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacek Laskowski <eljo...@gmail.com>
Subject Re: Geronimo 2.0
Date Fri, 06 Jan 2006 22:19:54 GMT
2006/1/6, David Jencks <david_jencks@yahoo.com>:
> Either I don't understand what is being proposed or I think it is a
> recipe for disaster.

Hi Dave,

I think there might be the third option ;)

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

Well, the more branches we will have the more headaches it will cause
to us. I think that's totally unavoidable when moving towards JEE 5
where Java 5 plays a crucial role.

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

Correct.

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

That's exactly what was said. Noone suggested to work on HEAD and
eventually breaks it for weeks. I think one of the reason we switched
to svn was the simplicity to create and merge a branch. We can
therefore easily experiment in our own branches, but that contradicts
what you said above with "more than one main development area". It's
unavoidable in such a large project to have only "one main development
area". There's going to be lots of branches, imho.

As far as EJB 3 is concerned it shouldn't be a big deal. It will be
implemented by OpenEJB which is a separate project so appropriate
interfaces should do the work nicely. The real pain will be with the
other modules that will require separate branches and be merged once
finished.

> 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 don't understand. Why are you scared of using Java 5? Geronimo 1.0
is on its own branch, and anybody who wants to play with the source
code will download that branch. Others who want to be on the cutting
edge will work with HEAD. Problems will have to be sorted out for
sure, but Geronimo 1.0 is safe and so are their minor descendants
(i.e. 1.x.x versions).

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

But that wouldn't be 1.0 any more, but a branch called 1.0.x or 1.x.
Weren't you worried about having more than one main development area?
Aren't you proposing just that?

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

That's acceptable, but how long do you envision HEAD will survive
before migrating to Java 5? Why don't you want to start using Java 5
right away? I don't remember who was it (possibly Dain) who expressed
so much enthusiasm about using Java Generics and I really think it
will save us a lot of time when developing with Java 5 instead of
writing code that will be a nightmare to support. Ok, maybe it won't
be a nightmare, but the additional code to support Java 1.4 will add
unnecessary burden.

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

That's an interesting matter. What changes make 1.x and what does
1.0.x? Anyone could comment on it. I think the security issue of Jetty
asks for 1.0.x.

> david jencks

Jacek

Mime
View raw message