commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Benedict" <pbened...@apache.org>
Subject Re: [io] 2.0 Moving to minimum of JDK 1.5
Date Wed, 06 Feb 2008 15:59:10 GMT
Niall, I agree as well. I don't see a strong reason for keeping any
deprecations if the package structure is changing. It is no longer binary
compatible -- especially if you begin at version 1.0 again.

Paul

On Feb 6, 2008 9:46 AM, Niall Pemberton <niall.pemberton@gmail.com> wrote:

> On Feb 6, 2008 1:44 PM, Simon Kitching <simon.kitching@chello.at> wrote:
> > ---- Stephen Colebourne <scolebourne@btopenworld.com> schrieb:
> > > Deprecation is useful when a method has been
> > > implemented incorrectly, and we want to push users
> > > to a replacement, or for similar issues. Removing deprecated
> > > classes/methods should be considered in a major version change,
> > > but even there we should question what the gain is. Having a
> > > 'nice and clean' no deprecations API release isn't sufficient a
> > > reason. We must always put the convenience of our users ahead of
> > > our natural refactoring and coding instincts.
> >
> > +1
> >
> > If a deprecated method is blocking significant improvement of the
> product, then ok remove it. But just to "clean up" is not really a good
> enough excuse.
>
> I don't mind the deprecations staying for IO 2.x - just thought that
> if there was going to be a package rename for JDK 1.5, then may as
> well clean up the deprecations as well. If, because of generic erasure
> IO 2.x isn't incompatible (except for the requirement for a higher JDK
> version) then how about retaining the current package name?
>
> Niall
>
> > > The problem is that there is no practical solution to a jar
> > > hell situation. Thus, it is our absolute responsibility to
> > > do everything in our power to avoid us being the cause of it.
> >
> > Over the last two weeks I've been working on embedding jspwiki into a
> locally developed application. Now jspwiki is compiled against Lucene
> 1.4.3, but the app already uses Lucene 2.3.0. And yep, they are
> incompatible (slightly, but enough).
> >
> > Fortunately jspwiki's search functionality is "pluggable" so by
> rewriting one jspwiki class I could make things work. But if the problem
> library had been more deeply embedded into the two systems I don't know what
> I could possibly have done.
> >
> > Of course if the new release was org.apache.lucene2, then there would be
> no problem.
> >
> > Compatibility is important.
> >
> > Regards, Simon
> >
> >
> > ---------------------------------------------------------------------
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message