commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oberhuber, Martin" <Martin.Oberhu...@windriver.com>
Subject RE: Commons Net 1.5 / 2.0 Releases
Date Wed, 21 May 2008 17:34:48 GMT
Hi Jörg,

Good point -- but in my environment (Eclipse), transitive
Deps are a non-issue since OSGi provides multiple classloaders
So I can live with ACN 1.5 and 2.0 at the same time even if
They have mutually incompatible implementations of the same
Class in the same namespace.

I'd rather like to have the ability to choose ACN 1.5 or
2.0 when my app happens to use only such parts of the lib
That happen to have changed in a non-breaking manner.
I cannot see why moving to Java5 forces binary breaking 
Changes -- after all the Java5 collections can be called
>From older Java too thanks to the concept of Erasures.

Of course I'm not talking about forced backward compatibility
In all cases. This is a major release, and it's one for good
Reason. I'm just talking about not breaking compatibility
Unless there is good reason for doing so.

And refactoring those small protocol impls into separate
Namespaces each is not a good reason IMHO. But perhaps
Somebody could argue to convince me why this is a good
And important thing?

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -----Original Message-----
> From: Jörg Schaible [mailto:Joerg.Schaible@elsag-solutions.com] 
> Sent: Mittwoch, 21. Mai 2008 07:55
> To: Commons Developers List
> Subject: RE: Commons Net 1.5 / 2.0 Releases
> 
> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message