[VOTE] Release [net] version 2.0

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[VOTE] Release [net] version 2.0

Rory Winston-3
Hi all

I would like to gauge support for a release of Commons::Net 2.0. The
major changes are:

* FTPS (SSL/TLS) support has been added
* FTPClient doesnt extend TelnetClient any longer
* The build now uses Maven 2
* [net] is now standalone - no external dependencies outside the JDK itself
* One new FTP parser (Netware) has been added, and the MVS parser has
been heavily updated
* A mini "FTP-only" jar (~ 90k) is available for clients who just need
FTP functionality
* Deprecated classes and methods have been removed

A full list of changes can be found here:

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

I have made the distribution (*unsigned* as yet) available for inspection:

http://people.apache.org/~rwinston/commons-net-2.0/

And the site is available:

http://people.apache.org/~rwinston/commons-net-2.0/site/


Thanks
Rory




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release [net] version 2.0

Steve Cohen
Rory Winston wrote:

> Hi all
>
> I would like to gauge support for a release of Commons::Net 2.0. The
> major changes are:
>
> * FTPS (SSL/TLS) support has been added
> * FTPClient doesnt extend TelnetClient any longer
> * The build now uses Maven 2
> * [net] is now standalone - no external dependencies outside the JDK itself
> * One new FTP parser (Netware) has been added, and the MVS parser has
> been heavily updated
> * A mini "FTP-only" jar (~ 90k) is available for clients who just need
> FTP functionality
> * Deprecated classes and methods have been removed
>
> A full list of changes can be found here:
>
> http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html
>
> I have made the distribution (*unsigned* as yet) available for inspection:
>
> http://people.apache.org/~rwinston/commons-net-2.0/
>
> And the site is available:
>
> http://people.apache.org/~rwinston/commons-net-2.0/site/
>
>
> Thanks
> Rory
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
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?

Steve Cohen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0

Stephen Colebourne
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).

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.*.

With this change, a user can have both the old and the new commons-net
jars in their classpath without any conflicts. 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.

Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0

Simon Kitching
On Sun, 2006-09-10 at 00:39 +0100, Stephen Colebourne wrote:
> Steve Cohen wrote:
> [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.*.
>
> With this change, a user can have both the old and the new commons-net
> jars in their classpath without any conflicts. Note that these users may
> be different OSS projects, which may upgrade at different times.

As Steve Cohen notes, I'd also be interested to see what features of
commons-net really benefit from a 1.5-compatible release.

However in general it seems a good time for commons to start releasing
code using 1.5 features where there is a benefit to the user. Java 1.5
is now well-established and the features are truly useful.

And I'm +1 to a new package name when doing so (as steve Colebourne
suggests) , to allow the old and new versions to co-exist.

I agree that requiring all apps to have *either* net 1.x or net 2.x in
the path, but not both, will cause a great deal of pain, and will
probably slow the adoption of the new net version.

BTW, It would be great if Java had some other mechanism for handling
multiple versions of the same library (as Microsoft's CLR has I
believe)..

Cheers,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0

Brett Porter-2

On 10/09/2006, at 12:40 PM, Simon Kitching wrote:
> BTW, It would be great if Java had some other mechanism for handling
> multiple versions of the same library (as Microsoft's CLR has I
> believe)..

As an ASF committer, you are welcome to participate in our  
involvement in JSR 277. See http://www.apache.org/jcp/ for details.

Cheers,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0

Henri Yandell
In reply to this post by Stephen Colebourne
On 9/9/06, Stephen Colebourne <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0

Rory Winston-3
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0

Steve Cohen
Continuing the discussion:

1.  Regex support is in 1.4.  It's only because we were trying to stay 1.2/1.3
compatible that we couldn't use it.  That's a small point.  I doubt we want to
have (say) a 1.4.2 branch that requires 1.4 after having supported 1.2/1.3 for
all these years, if our soon-to-be target is 1.5.  I do agree that the oro
dependency has been a very annoying pebble in the shoe.

2.  I'm not comfortable with the .net5 package name.  I see a cvs nightmare down
that road.  I guess SVN can handle that but it's still ugly.  It makes upgrade
for clients of net a maintenance nightmare.

3.  > 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.

No, there unfortunately does need to be this debate.  Sun has not end-of-lifed
1.4.2.  That is important.  They continue to release new subreleases of 1.4.2.
Why?  Important clients are still not ready to use 5.0.  My employer, a very
large corporation, now mandates the use of 5.0 but is forced immediately to
relent on this mandate for some of its most important projects because it also
still uses a lot of Websphere which still does not support 5.0 (and won't until
WebSphere 7 is released and even then it will be some time before the server
teams are ready to make that switch - they dragged their feet on Websphere 6
until recently).  So Sun has to support 1.4 (and continues to have to make new
subreleases of 1.4.2 for reasons such as the new daylight savings time start/end
dates).  The world marches on even when corporate java clients do not.

Backward compatibility's a bitch, but if Sun has to worry about this, I think we
do too.  I don't think jakarta-commons has ever "downgraded" a version of java
that Sun considers live.

And yet, as Rory says, there are some compelling reasons to do so. I'd love to
use JDK 5.0.  It hasn't been a possibility for me yet.  Even outside of work,
for a long time Eclipse did not support 5.0 although I don't think it is anymore.

So what is the solution?  What does it mean to say "not at the expense of
existing users on older versions?" I think we'd need to modify the site to have
full support for two release branches, with some easy switch between them.
There should be navigation menu items on the 2.0 site that point back to the
1.4.x site and vice versa as is the case with Tomcat and other projects.  We
can't just say all new development will be on 2.0, we'll continue to make 1.4.1
available for those who can't make the move.  We may want to say that, but I
don't think our user base will let us.  Until Sun EOL's 1.4.x, I think our
policy must be that every change that can be supported on pre-2.0 will be
supported there.

I also wonder if this should be a jakarta-commons-wide policy and not just
something that net does.


Rory Winston wrote:

> 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release [net] version 2.0

Rahul Akolkar
In reply to this post by Steve Cohen
On 9/9/06, Steve Cohen <[hidden email]> wrote:
<snip/>
>
> 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.
>
<snap/>

I see this has spawned the necessary discussion, and I'm unlikely to
vote until that discussion reaches some semblance of completion.

-Rahul


> 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?
>
> Steve Cohen
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0

Rahul Akolkar
In reply to this post by Steve Cohen
On 9/10/06, Steve Cohen <[hidden email]> wrote:

> Continuing the discussion:
>
> 1.  Regex support is in 1.4.  It's only because we were trying to stay 1.2/1.3
> compatible that we couldn't use it.  That's a small point.  I doubt we want to
> have (say) a 1.4.2 branch that requires 1.4 after having supported 1.2/1.3 for
> all these years, if our soon-to-be target is 1.5.  I do agree that the oro
> dependency has been a very annoying pebble in the shoe.
>
> 2.  I'm not comfortable with the .net5 package name.  I see a cvs nightmare down
> that road.  I guess SVN can handle that but it's still ugly.  It makes upgrade
> for clients of net a maintenance nightmare.
>
> 3.  > 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.
>
> No, there unfortunately does need to be this debate.  Sun has not end-of-lifed
> 1.4.2.  That is important.  They continue to release new subreleases of 1.4.2.
> Why?  Important clients are still not ready to use 5.0.  My employer, a very
> large corporation, now mandates the use of 5.0 but is forced immediately to
> relent on this mandate for some of its most important projects because it also
> still uses a lot of Websphere which still does not support 5.0 (and won't until
> WebSphere 7 is released and even then it will be some time before the server
> teams are ready to make that switch - they dragged their feet on Websphere 6
> until recently).  So Sun has to support 1.4 (and continues to have to make new
> subreleases of 1.4.2 for reasons such as the new daylight savings time start/end
> dates).  The world marches on even when corporate java clients do not.
>
> Backward compatibility's a bitch, but if Sun has to worry about this, I think we
> do too.  I don't think jakarta-commons has ever "downgraded" a version of java
> that Sun considers live.
>
> And yet, as Rory says, there are some compelling reasons to do so. I'd love to
> use JDK 5.0.  It hasn't been a possibility for me yet.  Even outside of work,
> for a long time Eclipse did not support 5.0 although I don't think it is anymore.
>
> So what is the solution?  What does it mean to say "not at the expense of
> existing users on older versions?" I think we'd need to modify the site to have
> full support for two release branches, with some easy switch between them.
> There should be navigation menu items on the 2.0 site that point back to the
> 1.4.x site and vice versa as is the case with Tomcat and other projects.  We
> can't just say all new development will be on 2.0, we'll continue to make 1.4.1
> available for those who can't make the move.  We may want to say that, but I
> don't think our user base will let us.  Until Sun EOL's 1.4.x, I think our
> policy must be that every change that can be supported on pre-2.0 will be
> supported there.
>
> I also wonder if this should be a jakarta-commons-wide policy and not just
> something that net does.
>
<snip/>

Mostly agree to Steve's note above. IMO:

 * New projects have a choice to start off with 1.4 (the least version
that hasn't begun the EOL process) -- as did SCXML. Unless ofcourse,
the central concept of the component itself is based on a 1.5 (or
higher) feature.

 * Older projects need to atleast support 1.4 (with active development
as in ports back from a 1.5 branch where possible etc.) until 1.4
begins to be EOL'ed. Again, above caveat will apply.

Having said that, I've been a proponent of 1.5 branches (and now
releases, as long as they're preceded by suitable discussion).

As a sidebar, Hen -- I feel your pain about having to go <=1.2 for
certain releases. Personally, I won't even think about RM'ing anything
that needs those. In the end, if its causing much grief that hampers
releases, perhaps that baseline may need revisiting.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0

Rory Winston-3
In reply to this post by Steve Cohen
I agree with the major points that Steve has made below. I would think
that a logical way to go (at least for [net]} would be :

* Version 2.0 (JDK 5.0+) becomes the main development branch, and the
focal point for new features;
* Version 1.x continues to be supported, in that fixes and new features
are backported where possible, and code submitted by the community
targeted at the 1.x branch can still be applied.

I think this is a pretty reasonable way of moving forward, encouraging
new development on a codebase free of the shackles of legacy
limitations, whilst still being able to service users with more
conservative requirements.


Rory



Steve Cohen wrote:

> Continuing the discussion:
>
> 1.  Regex support is in 1.4.  It's only because we were trying to stay
> 1.2/1.3 compatible that we couldn't use it.  That's a small point.  I
> doubt we want to have (say) a 1.4.2 branch that requires 1.4 after
> having supported 1.2/1.3 for all these years, if our soon-to-be target
> is 1.5.  I do agree that the oro dependency has been a very annoying
> pebble in the shoe.
>
> 2.  I'm not comfortable with the .net5 package name.  I see a cvs
> nightmare down that road.  I guess SVN can handle that but it's still
> ugly.  It makes upgrade for clients of net a maintenance nightmare.
>
> 3.  > 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.
>
> No, there unfortunately does need to be this debate.  Sun has not
> end-of-lifed 1.4.2.  That is important.  They continue to release new
> subreleases of 1.4.2. Why?  Important clients are still not ready to
> use 5.0.  My employer, a very large corporation, now mandates the use
> of 5.0 but is forced immediately to relent on this mandate for some of
> its most important projects because it also still uses a lot of
> Websphere which still does not support 5.0 (and won't until WebSphere
> 7 is released and even then it will be some time before the server
> teams are ready to make that switch - they dragged their feet on
> Websphere 6 until recently).  So Sun has to support 1.4 (and continues
> to have to make new subreleases of 1.4.2 for reasons such as the new
> daylight savings time start/end dates).  The world marches on even
> when corporate java clients do not.
>
> Backward compatibility's a bitch, but if Sun has to worry about this,
> I think we do too.  I don't think jakarta-commons has ever
> "downgraded" a version of java that Sun considers live.
>
> And yet, as Rory says, there are some compelling reasons to do so. I'd
> love to use JDK 5.0.  It hasn't been a possibility for me yet.  Even
> outside of work, for a long time Eclipse did not support 5.0 although
> I don't think it is anymore.
>
> So what is the solution?  What does it mean to say "not at the expense
> of existing users on older versions?" I think we'd need to modify the
> site to have full support for two release branches, with some easy
> switch between them. There should be navigation menu items on the 2.0
> site that point back to the 1.4.x site and vice versa as is the case
> with Tomcat and other projects.  We can't just say all new development
> will be on 2.0, we'll continue to make 1.4.1 available for those who
> can't make the move.  We may want to say that, but I don't think our
> user base will let us.  Until Sun EOL's 1.4.x, I think our policy must
> be that every change that can be supported on pre-2.0 will be
> supported there.
>
> I also wonder if this should be a jakarta-commons-wide policy and not
> just something that net does.
>
>
> Rory Winston wrote:
>> 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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0

Steve Cohen
I think we are in agreement.  I would be available to do some of the backporting
work if we go down this path.

Does anyone have anything to say about making the site a dual site (something
like Tomcat does)?  How difficult is that?  Does Maven 2 aid in such a process,
can it build a site from two different SVN branches at once?  Or is it really
just two sites that link to one another?


Rory Winston wrote:

> I agree with the major points that Steve has made below. I would think
> that a logical way to go (at least for [net]} would be :
>
> * Version 2.0 (JDK 5.0+) becomes the main development branch, and the
> focal point for new features;
> * Version 1.x continues to be supported, in that fixes and new features
> are backported where possible, and code submitted by the community
> targeted at the 1.x branch can still be applied.
>
> I think this is a pretty reasonable way of moving forward, encouraging
> new development on a codebase free of the shackles of legacy
> limitations, whilst still being able to service users with more
> conservative requirements.
>
>
> Rory
>
>
>
> Steve Cohen wrote:
>> Continuing the discussion:
>>
>> 1.  Regex support is in 1.4.  It's only because we were trying to stay
>> 1.2/1.3 compatible that we couldn't use it.  That's a small point.  I
>> doubt we want to have (say) a 1.4.2 branch that requires 1.4 after
>> having supported 1.2/1.3 for all these years, if our soon-to-be target
>> is 1.5.  I do agree that the oro dependency has been a very annoying
>> pebble in the shoe.
>>
>> 2.  I'm not comfortable with the .net5 package name.  I see a cvs
>> nightmare down that road.  I guess SVN can handle that but it's still
>> ugly.  It makes upgrade for clients of net a maintenance nightmare.
>>
>> 3.  > 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.
>>
>> No, there unfortunately does need to be this debate.  Sun has not
>> end-of-lifed 1.4.2.  That is important.  They continue to release new
>> subreleases of 1.4.2. Why?  Important clients are still not ready to
>> use 5.0.  My employer, a very large corporation, now mandates the use
>> of 5.0 but is forced immediately to relent on this mandate for some of
>> its most important projects because it also still uses a lot of
>> Websphere which still does not support 5.0 (and won't until WebSphere
>> 7 is released and even then it will be some time before the server
>> teams are ready to make that switch - they dragged their feet on
>> Websphere 6 until recently).  So Sun has to support 1.4 (and continues
>> to have to make new subreleases of 1.4.2 for reasons such as the new
>> daylight savings time start/end dates).  The world marches on even
>> when corporate java clients do not.
>>
>> Backward compatibility's a bitch, but if Sun has to worry about this,
>> I think we do too.  I don't think jakarta-commons has ever
>> "downgraded" a version of java that Sun considers live.
>>
>> And yet, as Rory says, there are some compelling reasons to do so. I'd
>> love to use JDK 5.0.  It hasn't been a possibility for me yet.  Even
>> outside of work, for a long time Eclipse did not support 5.0 although
>> I don't think it is anymore.
>>
>> So what is the solution?  What does it mean to say "not at the expense
>> of existing users on older versions?" I think we'd need to modify the
>> site to have full support for two release branches, with some easy
>> switch between them. There should be navigation menu items on the 2.0
>> site that point back to the 1.4.x site and vice versa as is the case
>> with Tomcat and other projects.  We can't just say all new development
>> will be on 2.0, we'll continue to make 1.4.1 available for those who
>> can't make the move.  We may want to say that, but I don't think our
>> user base will let us.  Until Sun EOL's 1.4.x, I think our policy must
>> be that every change that can be supported on pre-2.0 will be
>> supported there.
>>
>> I also wonder if this should be a jakarta-commons-wide policy and not
>> just something that net does.
>>
>>
>> Rory Winston wrote:
>>> 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 <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0

jochen-2
May I point out, that tools like retroweaver or retrotranslator can be
used to write code with most 1.5 features while still compiling for
1.4? I don't know whether this applies to the commons-net project, but
for most projects I know, this should still be fine.


Jochen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0

Henri Yandell
How does that work exactly? Can we happily write 1.5 stuff and then
let the user take the 1.5 jar and retroweave it before using it, or do
we have to integrate retroweaver into our builds (though not our
sources I hope?)?

Hen

On 9/10/06, Jochen Wiedmann <[hidden email]> wrote:

> May I point out, that tools like retroweaver or retrotranslator can be
> used to write code with most 1.5 features while still compiling for
> 1.4? I don't know whether this applies to the commons-net project, but
> for most projects I know, this should still be fine.
>
>
> Jochen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0

Brett Porter-2
You'd integrate it into your builds. However, this doesn't help with  
missing APIs (though I believe retrotranslator does take care of some  
of these). It's a pretty good solution for providing JDK 5 binaries  
for JDK 1.4.

However, I don't think this addresses the issue being faced - and it  
isn't entirely a JDK 5 related one, but something that is faced  
whenever a component might want an extreme makeover.

IMO, this is the best pattern to follow:
- keep the maintenance branches going for the previous release, and  
bump trunk to the next major version
- if new functionality can be isolated to a new package or a separate  
module, do that (eg, some libraries like xwork have an xwork-tiger  
module for jdk5 related code)
- if the update can remain api compatible, then there is no need to  
change package names (eg, the JDK added generics to a lot of the  
runtime without making incompatible changes to the public interfaces)
- if the update must change the api, consider changing the package  
name (but only do so if there is a need to use both versions of the  
jar in a single classloader, for example lucene was able to safely  
overhaul their api for 2.0 because it would be unlikely both would be  
in the same classloader)

Obviously, the final one is a last resort and should be avoided -  
especially since that case would be quite prevalent for commons. If  
it really really really was needed for some reason, I'd call it  
o.a.c.net2 (or hopefully something better) rather than net5,  
reflecting the API not the JDK it is designed for because that'll  
quickly be outdated as JDK 6 comes out.

I think these are all general principles to apply to API evolution,  
not just for JDK 5 related changes. Didn't collections go through  
this (backwards-incompatible API change, not a JDK5-ification) Îin  
the past for 3.0? Any experiences that can be learned from there?

HTH,
Brett

On 11/09/2006, at 7:16 AM, Henri Yandell wrote:

> How does that work exactly? Can we happily write 1.5 stuff and then
> let the user take the 1.5 jar and retroweave it before using it, or do
> we have to integrate retroweaver into our builds (though not our
> sources I hope?)?
>
> Hen
>
> On 9/10/06, Jochen Wiedmann <[hidden email]> wrote:
>> May I point out, that tools like retroweaver or retrotranslator  
>> can be
>> used to write code with most 1.5 features while still compiling for
>> 1.4? I don't know whether this applies to the commons-net project,  
>> but
>> for most projects I know, this should still be fine.
>>
>>
>> Jochen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0

Stephen Colebourne
Brett Porter wrote:
> Didn't collections go through  this
> (backwards-incompatible API change, not a JDK5-ification) Îin  the past
> for 3.0? Any experiences that can be learned from there?

[collections] 3.0 has been FUDed with the backwards incompatible tag
ever since it was released, but it was never exactly true. The release
rewrote many classes, and tidied many APIs, but did so by moving them
into new packages. The original classes were deprecated, so no problems...

...except that one backwards incompatible change did sneak in - where
the return type of a constant was changed. The clirr tool would have
caught it, but didn't exist then.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[PROPOSAL] Commons and API change

Stephen Colebourne
In reply to this post by Henri Yandell
Some interesting points have been made so far. I believe I should
restate my proposal based on feedback (especially as the original was
written just after a weeks holiday...):

[PROPOSAL]
Whenever a project performs a backwards incompatible API change, two
things must happen:
a) the major version is increased, eg. from 1.2 to 2.0
b) the package name is changed from o.a.c.foo to o.a.c.foo2, or
alternatively to a completely new name, eg. o.a.c.bar
[/PROPOSAL]

Thus, this isn't really a JDK5 issue, but a basic issue of dependency
management. And hence, as poined out, the API version number should be used.

Note however that it is possible to go up a major version without the
proposed rule being enforced *if* and only if there are no backwards
incompatible changes (removal of deprecations allowed).

Now, I would suggest that many projects going from a JDK1.2/3/4 base to
a JDK1.5 base will want to (and should!) make API changes (also, because
of generics et al its difficult to know if you *have* actually made a
backwards incompatible change!) As such, I would expect these 1.5
projects to be subject to the rule in the proposal.

I understand that this is a bit of a pain for end users, but its a pain
because of the lack of a module system as per JSR277. I would argue that
changing a package name to migrate is infinitely preferable when dealing
with a library to coming up against an insoluble jar hell scenario.

Remember, [collections] took one small human error to cause an
incredible amount of FUD and bad press about commons, that still reduces
our user-base today. *Every* jar-hell scenario that is created worsens
this. AFAIK, package renaming is the best, most-viable solution to
backwards incompatible change in Java today.

Stephen


Henri Yandell wrote:

>> [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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0

Brett Porter-2
In reply to this post by Stephen Colebourne
oops! Thanks for the clarification - I'd never had any problems  
myself, but I thought I'd gotten that indication from the release  
notes/web site. Long while ago now, obviously my memory isn't so good.

- Brett

On 11/09/2006, at 7:55 AM, Stephen Colebourne wrote:

> Brett Porter wrote:
>> Didn't collections go through  this (backwards-incompatible API  
>> change, not a JDK5-ification) Îin  the past for 3.0? Any  
>> experiences that can be learned from there?
>
> [collections] 3.0 has been FUDed with the backwards incompatible  
> tag ever since it was released, but it was never exactly true. The  
> release rewrote many classes, and tidied many APIs, but did so by  
> moving them into new packages. The original classes were  
> deprecated, so no problems...
>
> ...except that one backwards incompatible change did sneak in -  
> where the return type of a constant was changed. The clirr tool  
> would have caught it, but didn't exist then.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[VOTE] Release [net] version 2.0

Rory Winston-3
In reply to this post by Steve Cohen
OK, seeing as we have reached some kind of consensus on how to handle
backards-incompatible JDK releases, I'm restarting the vote for a
release of Commons::Net 2.0 (the JDK 5.0 branch).

As per usual, just respond with

+1
+0
-0
-1

Thanks
Rory

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release [net] version 2.0

Steve Cohen
Rory Winston wrote:

> OK, seeing as we have reached some kind of consensus on how to handle
> backards-incompatible JDK releases, I'm restarting the vote for a
> release of Commons::Net 2.0 (the JDK 5.0 branch).
>
> As per usual, just respond with
>
> +1
> +0
> -0
> -1
>
> Thanks
> Rory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
Sorry, Rory, but I think you need to express the consensus that you think we are
voting on.  You haven't done that.  "release of Commons::Net 2.0 (the JDK 5.0
branch)" doesn't get to the heart of all the issues.

1: Are there two "official" branches or is 1.4.x relegated to "backward
compatibility mode"?  I would insist that there be two branches until Sun puts
1.4.x into EndOfLife mode.

2. Is the site going to be organized to reflect the two branches?

If those two points are part of your "motion", I'm +1.  Otherwise, I'm -1.

Steve

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12