Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of cdoronc@gmail.com designates
 72.14.220.156 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=RdWQZb5HydSEPFY0VeQADprJuzKHobgZOuvovyLdD6/qUlyUFs3l6hon9SWuckLyApejdwPtq0sUgXSuw6sIcdHXW/r8CXNqyLDCOltn2JxrUUebfqPjeTiCYDaAQUb9nQaz5gdH2CXUZK9D/Ud7H1XCaETn00Qbnl0PKUFJk8E=
Message-ID: <e05f0fd10803100902k4af2d4f2i14ba2fcfb0b8f62e@mail.gmail.com>
Date: Mon, 10 Mar 2008 18:02:09 +0200
From: "Doron Cohen" <cdoronc@gmail.com>
To: java-dev@lucene.apache.org
Subject: Re: Going to Java 5. Was: Re: A bit of planning
In-Reply-To: <E07D1A07-E0B9-4AC1-81BC-88D552BDB5E7@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_11177_22007328.1205164929555"
References: <818426B2-8C2C-4E6C-AB61-C01B6FC07B2D@apache.org>
	 <47894B0D.1030700@gmail.com> <47894CF8.9080006@gmail.com>
	 <Pine.LNX.4.62.0801121533210.351@radix.cryptio.net>
	 <9E5E7C49-0386-4D45-A4B6-A82B4A4821F0@gmail.com>
	 <Pine.LNX.4.62.0801162212480.32552@radix.cryptio.net>
	 <E07D1A07-E0B9-4AC1-81BC-88D552BDB5E7@gmail.com>

------=_Part_11177_22007328.1205164929555
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Thu, Jan 17, 2008 at 4:01 PM, DM Smith <dmsmith555@gmail.com> wrote:

>
> On Jan 17, 2008, at 1:38 AM, Chris Hostetter wrote:
>
> > : I'd like to recommend that 3.0 contain the new Java 5 API changes
> > and what it
> > : replaces be marked deprecated. 3.0 would also remove what was
> > deprecated in
> > : 2.9. Then in 3.1 we remove the deprecations.
> >
> > FWIW: This would violate the compatibility requirements, since code
> > that
> > compiles against 3.0 (with deprecation warnings) wouldn't compile
> > against
> > 3.1 -- but then again: there has been some mention of revisting the
> > entire
> > back compatibility commitments of Lucene, and now certainly seems
> > like the time
> > to discuss that before too much work is done in any particular
> > direction
> > in an attempt to "head towards" 2.9/3.0.
>
> Any way that it goes, my point is that it needs to be a two step
> process. The additional step needs to address the language differences.
>
> Maybe after 2.9, we add 2.9.5 (or whatever) that introduces the Java 5
> APIs, with appropriate deprecations. 2.9.5 would require Java 1.5.


Since going to Java 5 is a major change, I think it is not too wild to
go from 3.0 straight to 4.0..?  Main (and perhaps only) change would be
moving to Java 5. This way we don't break any back.comp requirements.

------=_Part_11177_22007328.1205164929555--