Hey guys

An interesting discussion here. I'll try to address some of the points raised and give my take on the issue.

* As far as [net] specifically is concerned, there are very few things that 1.5 makes possible that you really can't do on 1.3 (One of these is asynchronous I/O and a select()-based thread notification model). However, 1.5 does make a *ton* of things much cleaner. For instance, regex support is now on a par with [oro], so we lose our only external dependency, making [net] a self-contained single jar download. We can also support secure FTP without having to install a separate JSSE jar, as SSL/TLS support is now integral in JCE. Apart from that, there are many, many, smaller enhancements that we can make. See

http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html#2.0

for a few.

* As far as I am concerned, the ideal scenario for a project like [net] is that 1.5+ support continues on a different version line. It may be the trunk, it may be a branch. So for [net], the 1.x line is for JDK 1.4.x and below, and the 2.0 line is 1.5+. It doesn't in any way mean that support is suddenly dropped for pre-Tiger releases. But sooner or later, 2.0 is the main development version, and that's where the effort should go.

* I don't like the concept of a ".net5" package name. Does this mean that we need a ".net6" package space when JDK 6 is released? It doesn't feel elegant, and it loses one of the big advantages that the current system has : a user can upgrade their JDK from 1.3 to 5.0 overnight, download a new [net] 2.0 jar, and their FTPClient-based code should *just work* (with a 90% probability ;)).

* I agree with Henri's comment below about Commons being a "maintenance" vs. "development" space. JDK 5.0 has been officially released for around two years. In my opinion, there shouldn't even be a debate. It should be taken advantage of, and supported, although not at the expense of existing users on older versions.

Cheers
Rory



Henri Yandell wrote:
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]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to