: This proposal was just for the next (1.5?) release cycle though.
...
: I agree though - there is rapid movement in Lucene these days, and things can
: be pulled back or altered fairly easily during trunk dev. Sometimes even index
: format changing issues - which can be a real pain (having suffered that first
: hand in the past). The closer we can stay to actual Lucene releases in
: general, the better I think.
I suggest we not worry about it too much until the situation arrises.
Once upon a time the decision to bump the lucene-java rev in Solr was
drien largely based on wether we people that that version was had useful
additions *and* was relatively "solid". My impression more recently is
that people have been bumping the rev primarily with the
features/improvements in mind, and less consideration of the stability --
probably due to the (completely valid) assumption that solr trunk doesn't
*need* to be any more stable then the lucene-java trunk, so we might as
well go ahead and rev and help shake things out.
If we go back in hindsight with and imagine that Solr might have be
released at any given moment, then some of those lucene-java revs would
probably seem less prudent then others.
Moving forward we should just proceed the same way: don't rev any Solr
deps (lucene-java or otherwise) unless you're confident enough in the new
version that you'd be ready to vote for a release that includes it.
If lucene-java maintains a really heavy state of churn on the trunk, then
nightlies probably aren't going to meet that criteria for us moving
forward -- but if, at some point in future, someone wants to bump the rev
to a nightly that is exactly the same as lucene-java 3.2.3 plus one new
TokenFilter they want to write a Factory for ... i really don't see that
as being less stable then the "stable" 3.2.3 version.
Common sense makes the most sense.
-Hoss
