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