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: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=btopenworld.com;
  h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
  b=eTLTLoxFQIC3JZyyZIogO+FpHqAj+KWk2SeKjhLGVV6JTSDgtlE/6ONWLvoVoLa5309arwbBLCFC2Rax3xMx2s7plhc+7MJUDhxIb1P5WhVN4owMKXYCcW00fR1FFpBLisx3hiPW8q31L2224PfG7OHo4MJ/eYkRrTpBVms3nD8=;
Date: Tue, 5 Feb 2008 13:27:54 +0000 (GMT)
From: Stephen Colebourne <scolebourne@btopenworld.com>
Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
To: Jakarta Commons Developers List <dev@commons.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID: <170098.70022.qm@web86508.mail.ird.yahoo.com>

> On Feb 4, 2008 8:47 PM, Niall Pemberton <niall.pemberton@gmail.com>  =0A>=
> From memory the preference was to move to a new package name  - how=0A>> =
about "org.apache.commons.io2"?=0ATo avoid confusion with version numbers, =
we could choose [io-two]:=0A org.apache.commons.io-two=0A=0A=0AOn 05.02.200=
8, at 06:44, Henri Yandell wrote:=0A> For Collections it makes sense as the=
re's a big API change planned.=0A> For the others, I think they should char=
ge in and see what kind of=0A API=0A> changes are required. If we're talkin=
g small ones, then I'd prefer=0A not=0A> to. I continue to not think that t=
he next major version of a jar has=0A> to kill itself over backwards compat=
ibility (ie: what's the point of=0A a=0A> major version).=0A=0ABecause it i=
s absolutely essential that we allow compatibility with the older release.=
=0A=0ASpecifically, it is a requirement that if there are any binary or sou=
rce incompatible changes, then an application must be able to run with both=
 the old and new jar files (v1.4 and v2.0). The only practical way in Java =
today is to have the two incompatible versions in two separate packages.=0A=
=0AThe practical impact of a new package is small to users that use commons=
-io directly - a quick organize imports in an IDE. The impact of NOT doing =
this would be jar hell, if your application relied on another open source l=
ibrary that still used v1.4.=0A=0A=0A>> Are there any objections to me crea=
ting an IO 1.4 branch from the=0A>> current trunk and then starting work on=
 IO 2.0 in the trunk.=0A> Any need to make the branch?=0A> ie) Wait until y=
ou need it; as long as you have a tag of the latest=0A> release you can alw=
ays branch from that.=0A=0AMy gut feeling is that TRUNK should be for v2.0.=
 The alternative of a separate commons component for [io-two] seems overkil=
l.=0A=0A=0AFrom: Torsten Curdt <tcurdt@apache.org>=0A> I think it would muc=
h more consistent to do it across the board.=0A=0AEach component will have =
to make their own decisions, but I suspect [io]/[lang]/[collections] will h=
elp guide the way.=0A=0A=0AStephen=0A=0A

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