Hi Martin,
Oberhuber, Martin wrote:
> Hi Rory,
>
> Thanks for your opinion -- but may I note that even if
> It's a major releases, there may be (some|many) existing
> Clients which are not broken even if they upgrade,
> Depending on what APIs their client code currently uses.
>
> Breaking clients for no good reason just isn't playing
> Nice with the clients IMHO, although you are right that
> You do have the chance doing so in a major release.
>
> At any rate, I wouldn't call the discussion irrelevant.
> It is relevant for clients picking up commons net when
> They migrate from 1.x to 2.x, and depending on what
> The clients do and how many different ones there are,
> Even Eclipse Ctrl+Shift+O can sum up to a non-trivial
> Amount of total work on behalf of the clients.
Basically there's no problem to deliver a commons-net-2.0-legacy.jar that
contains something along
package org.apache.commons.net;
class Echo extends org.apache.commons.net.echo.Echo { ... };
> I'm all in favor of code cleanup and refactoring when
> I see clear advantages, but not at any price.
>
> For our FTP clients, I'd love to see customers being
> Able to exchange net 1.5 against net 2.0 pre-compiled
> Binaries in the final product if possible.
However, this implies that ACN 1.x is binary compatible to ACN 2.0. However
that is simply neither guaranteed nor enforced. If ACN 2.x makes usage of Java
5 you will see some API breakage that prohibits 2.x to be used as drop in
replacement. That was simply not the goal of this design. However that's the
reason why *I* always recommend to use a different package name for major
releases with API breakage, simply to ensure that both versions can be used at
the same time. Not that a client wants to do this, but he might be forced to do
so because of transitive deps.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
