Grant Ingersoll wrote:
We voted to make 3.0 Java 1.5, full well knowing that it will break
the back compat. requirements. I don't see the point of postponing it
or dragging it out.
I thought his suggestion was to skip 3.0 as a designator and instead use
4.0. If so, the schedule would not change.
On Mar 10, 2008, at 12:02 PM, Doron Cohen wrote:
On Thu, Jan 17, 2008 at 4:01 PM, DM Smith <[EMAIL PROTECTED]> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
