commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject RE: Commons Net 1.5 / 2.0 Releases
Date Wed, 21 May 2008 05:54:35 GMT
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

class Echo extends { ... };

> 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:
For additional commands, e-mail:

View raw message