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
