Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <f2e8eedf0802060804y421724ah69b724a013ed0979@mail.gmail.com>
Date: Wed, 6 Feb 2008 11:04:54 -0500
From: "James Carman" <james@carmanconsulting.com>
Sender: jcarman@carmanconsulting.com
To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
In-Reply-To: <b9e663070802060759p195cc257j30e9d96ef89dc076@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1830492.1202305489591.JavaMail.root@viefep15>
	 <55afdc850802060746o131e08b6gbb6c38de4b5aed45@mail.gmail.com>
	 <b9e663070802060759p195cc257j30e9d96ef89dc076@mail.gmail.com>

On 2/6/08, Paul Benedict <pbenedict@apache.org> wrote:
> 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.

Version 1.0?  So, it'd be org.apache.commons.io2, but the release
would be version 1.0?  I don't know about that.  I'd think that
anything packaged in io2 packages would be released under a 2.x
release number.

>
> 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
> >
> >
>

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