geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Geronimo 2.0
Date Fri, 06 Jan 2006 19:10:18 GMT
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-----
>


Mime
View raw message