On 9/9/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
Steve Cohen wrote:
> I am not ready to vote yet on this until there is a discussion about
> what this release means. Will commons-net-2.0 become the "official"
> release, with previous versions relegated to "backward compatibility"
> support? If so, this may be premature as Sun is still supporting
> JDK-1.4.2-x.
>
> But I don't think we should stand in the way of progress either. Rory,
> can you comment on what are the specific new features that demand JDK
> 5.0 support?
>
> How have other jakarta-commons projects handled this? Are there any
> official versions that require 1.5? Are there projects that have two
> "official" releases?
I see this as a positive step (a JDK 1.5 only release).
I also see this as the right jump (from JDK 1.2/1.3 to 1.5).
I'm a strong +1 for JDK 1.5 dependence.
The way I see it is that while we're supporting 1.2->1.4, new
development happens on 1.5 so the only time we need to worry about
older JVMs is for critical bugfixes on maintenance systems - not for
new development.
Trying to focus on old JVMs makes us a maintenance project, not a
development project and that's damaging for the project health.
Lang 2.2 is in a limbo state because I can't get 1.2 for my Mac, I
need to dig into Ubuntu to try and get it to work there and I can't
even figure out how to get it to work on Windows at the moment (JDK
1.6 appears to be taking over the JAVA_HOME and PATH, but it's not
defined in the user's environment variables).
Another reason is that Lang has tests that fail to pass on 1.2 and
1.3; possibly due to bugs in the JVM (time crap). Even once I can make
a 1.2/1.3 build, I'm not sure if I should.
Plus other reasons, such as being without a happy laptop at home until
tonight :)
However, I believe that commons holds an almost unique place in Java
development being the lowest layer in many many open source projects. As
such making an incompatible major version change is a *very* big deal.
[PROPOSAL]
As such, I would like to propose that projects creating a JDK1.5 only
release should use a new package name. Thus, in this case, the release
would use the package org.apache.commons.net5.*.
-1 for a slew of reasons.
* Lots of source code would have to be touched just to upgrade; big
pain in the arse for something that is quite likely to not involve any
other change to a user's source.
* Building v49 class files is going to explode on a v48 JVM, so people
are going to be stopped pretty quickly from using the net5 on their
old JVM. We don't need to protect them via packages.
* Do we do net3 and net4 if we move from 1.2 to 1.3/1.4? Do we do net6?
With this change, a user can have both the old and the new commons-net
jars in their classpath without any conflicts.
Only a JDK 1.5 user (1.6 too I guess). Presuming we make 1.5 targetted
builds and not 1.2->1.4. And then it's nothing to do with 1.4/1.5 and
just the classic problem of package clash within dependencies.
Note that these users may be different OSS projects, which may upgrade at
different times.
Users wishing to migrate from one version to another can simply do a
global search and replace on the package name.
We must not underestimate the significance of the low-level position of
commons in the Java OSS, and proprietry, communities. A clear and
planned migration strategy for all our modules is needed.
I accept that by its nature Commons is going to cause problems every
time they release. We're going to be a frequent location for classpath
clash problems. It's not JVM relevant though, it happens every time we
release anything so the version you would need in the package name is
the Commons major version, not the jdk version.
I think we should declare that new development will be on 1.5 -
building 1.5 only jars. Anyone trying to use them on 1.4 and before is
going to get a nice error and we can start exploring new JDK features
like regular expressions *sarc :) *. Then we can stick with it until
1.8 is in beta or something.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
