Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of pats@acm.org designates
 209.86.89.62 as permitted sender)
Message-ID: <4CF149C4.8070405@acm.org>
Date: Sat, 27 Nov 2010 10:11:16 -0800
From: Patricia Shanahan <pats@acm.org>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: JVM version policy Was: Re: Build failed in Hudson:
 River-trunk-jdk1.5
 #3
References: <862502422.8331290517859184.JavaMail.hudson@aegis>
	<112459958.8391290520715806.JavaMail.hudson@aegis>	<4CEBDFC0.90506@qcg.nl>
 <AANLkTi=x13MS-gUsXMEWyrsm8UjCY-ghpTmO1WnQ+yjt@mail.gmail.com>
 <4CEBE8B0.2020806@qcg.nl> <4CEBED3F.3080504@acm.org>
 <77F1E32F67C8D5479858C0C7E93EB46503E19BB8@WAL-MAIL.global.avidww.com>
 <4CEC61DA.3030702@zeus.net.au> <4CECC1A5.7070804@qcg.nl>
 <4CED1D08.3030101@acm.org> <4CED23EA.1020208@qcg.nl>
 <4CED7C20.5010703@acm.org> <4CED8705.7050406@qcg.nl>
 <4CED9421.1070800@acm.org> <4CEE6C4A.6000908@zeus.net.au>
In-Reply-To: <4CEE6C4A.6000908@zeus.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Firmstone wrote:
> Well this is a tough one, here are some ideas:
> 
>   1. Branch what we have now for release and simply reset the compiler
>      flag, to jsr14, which buys time until we have a more modular
>      build, then based on what we know then, decide if ongoing support
>      for remote clients using Java 1.4 is feasible.  For this release,
>      test on Java 1.4, 5 and 6.  We could adopt a policy that if a bug
>      exists on Java 1.4 or 5, but not on 6, then the fix is to upgrade
>      to Java 6.  Users would of course be free to submit a patch, but
>      we wouldn't actively support the earlier platforms.
>   2. Compile on JDK 1.6 and support only Java 5 and 6, drop support for
>      communicating with remote Java 1.4 clients.  If we find that it is
>      later possible to support Java 1.4 clients with the modular build,
>      users can skip the current release.  Users can work around the
>      Java 1.4 communication issue if they need to, by using proxy
>      codebases from the previous release only.
...
> I think you touched on something earlier, it's important we address ease 
> of deployment.

In both cases, I think we want to encourage a move towards 6. Even in a 
corporate environment, it is often difficult to simultaneously upgrade 
to a new JVM for a lot of jobs, on different computers.

I'm interested in probing the path for a current 1.4 installation to 6 
for each approach. The more I think about it, the more I feel that 
keeping 1.4 as a common language for proxies might be an advantage.

Patricia