On Nov 19, 2009, at 3:34 PM, Mark Miller wrote:
Ryan McKinley wrote:
I would love to set goals that are ~3 months out so that we don't
have
another 1 year release cycle. For a 2.0 release where we could have
more back-compatibly flexibility, i would love to see some work that
may be too ambitious... In particular, the config spaghetti needs
some attention.
I don't see the need to increment solr to 2.0 for the lucene 3.0
change -- of course that needs to be noted, but incrementing the
major
number in solr only makes sense if we are going to change *solr*
significantly.
Lucene major numbers don't work that way, and I don't think Solr needs
to work that way be default. I think major numbers are better for
indicating backwards compat issues than major features with the way
these projects work. Which is why Yonik mentions 1.5 with weaker back
compat - its not just the fact that we are going to Lucene 3.x - its
that Solr still relies on some of the API's that won't be around in
3.x
- they are not all trivial to remove or to remove while preserving
back
compat.
I confess I don't know the details of the changes that have not yet
been integrated in solr -- the only lucene changes I am familiar with
is what was required for solr 1.4.
The lucene 2.x -> 3.0 upgrade path seems independent of that to
me. I
would even argue that with solr 1.4 we have already required many
lucene 3.0 changes -- All my custom lucene stuff had to be reworked
to
work with solr 1.4 (tokenizers & multi-reader filters).
Many - but certainly not all.
Just my luck... I'm batting 1000 :)
But that means my code can upgrade to 3.0 without a issue now!
In general, I wonder where the solr back-compatibility contract
applies (and to what degree). For solr, I would rank the
importance as:
#1 - the URL API syntax. Client query parameters should change as
little as possible
#2 - configuration
#3 - java APIs
Someone else would likely rank it differently - not everyone using
Solr
even uses HTTP with it. Someone heavily involved in custom plugins
might
care more about that than config. As a dev, I just plainly rank them
all
as important and treat them on a case by case basis.
I think it is fair to suggest that people will have the most stable/
consistent/seamless upgrade path if you stick to the HTTP API (and by
extension most of the solrj API)
I am not suggesting that the java APIs are not important and that back-
compatibly is not important. Solr has a some APIs with a clear
purpose, place, and intended use -- we need to take these very
seriously. We also have lots of APIs that are half baked and loosy
goosy. If a developer is working on the edges, i think it is fair to
expect more hickups in the upgrade path.
With that in mind, i think 'solr 1.5 with lucene 3.x' makes the most
sense. Unless we see making serious changes to solr that would
warrent a major release bump.
What is a serious change that would warrant a bump in your opinion?
for example:
- config overhaul. detangle the XML from the components. perhaps
using spring.
- major URL request changes. perhaps we change things to be more
RESTful -- perhaps let jersey take care of the URL/request building https://jersey.dev.java.net/
- perhaps OSGi support/control/configuration
Lucene has an explict back-compatibility contract:
http://wiki.apache.org/lucene-java/BackwardsCompatibility
I don't know if solr has one... if we make one, I would like it to
focus on the URL syntax+configuration
Its not nice to give people plugins and then not worry about back
compat
for them :)
i want to be nice. I just think that a different back compatibility
contract applies for solr then for lucene. It seems reasonable to
consider the HTTP API, configs, and java API independently.
From my perspective, saying "solr 1.5 uses lucene 3.0" implies
everything a plugin developer using lucene APIs needs to know about
the changes.
To be clear, I am not against bumping to solr 2.0 -- I just have high
aspirations (yet little time) for what a 2.0 bump could mean for solr.
ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
