lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <>
Subject Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Date Mon, 19 Jun 2006 22:45:35 GMT
I don't think this should be dismissed as a non-argument.  You want to live on the edge of
Lucene, but at the same time don't want to (probably can't, I know) use the current JVM that's
been out for a long time now (a year or more, I think, didn't check).  You can look at the
"but I want the latest Lucene" argument the other way around, too - I'd hate to lose contributions
with 1.5 code because it suits the minority to stay with 1.4.

I think Chuck's suggestion was the best one so far:
- allow 1.5 in trunk
- those who want/need 1.4 can back-port it

That way we don't reject 1.5 contributions, and those who need 1.4 can scratch their itch
by back-porting.  I doubt we'll get (m)any contributors to rewrite their code to work with
1.4 JVM if they aready used 1.5 stuff, even if it's just syntactic sugar.

Oh, and maybe we could say that 1.5 is okay only for new features, while any bug fix should
remain 1.4 compatible, so that patches can be applied to the 2.0.* branch.


----- Original Message ----
From: markharw00d <>
Sent: Monday, June 19, 2006 4:40:57 PM
Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)

 >>One point that I feel keeps getting ignored is that we are talking 
about the _future_ releases.
 >>My guess is that we won't see a major new Lucene release before 2007, 
and by that time the latest JVM will probably be 1.6.

I think that's a non-argument as it is common practice for people to 
work with the latest trunk version and in practice we have often 
recommended users to do so (a credit to the stability of the code and 
quality of commits).

e.g. Erik's post from;#30227

 >"The only difference between Subversion trunk and a released version
 >is the time and effort someone has taken to build it, package it,
 >sign it, and upload it (and of course a consensus vote authorizing
 >it). While I know that many environments demand that such blessing
 >has occurred, I cannot say that I altogether understand it. I much
 >prefer, personally, to be on the trunk and know that any issues I do
 >happen to encounter can be easily reported, likely fixed if
 >identified specifically enough, fixed, and integrated back into my
 >projects right away.

This decision is therefore not just one that will effect users in 2007 
but more likely as soon as we decide a 1.5 commit takes place.


All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message