lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: Solr 1.5 or 2.0?
Date Fri, 20 Nov 2009 02:05:39 GMT
Hey Yonik,

My personal experience with this is if you jump directly to 2.0, you'll have people wondering
where 1.5, 1.6-->1.9 is in the CM system, and this would create some confusion unless it
is documented well. This may warrant rethinking the tag structure a bit in SVN, or perhaps
even the regular trunk structure at some point down the road. What's the SOLR versioning scheme
by the way? Is it:

M.n

Where M is the major version #
Where n is the minor version #

In this type of scheme, all n's in a series are expected to be at least backwards compatible
with n-1 through 0-9, but all M+1's aren't necessarily compatible with M or M-1. We've used
this approach in Nutch and Tika land for a while and it's been pretty successful.

If this versioning scheme isn't documented somewhere, I'd be happy to throw up a page on the
Wiki. Let me know and thanks. With the right documentation, the move from 1.4->2.0 will
introduce less confusion, IMHO.

Cheers,
Chris

On 11/19/09 6:31 AM, "Yonik Seeley" <yonik@lucidimagination.com> wrote:

What should the next version of Solr be?

Options:
- have a Solr 1.5 with a lucene 2.9.x
- have a Solr 1.5 with a lucene 3.x, with weaker back compat given all
of the removed lucene deprecations from 2.9->3.0
- have a Solr 2.0 with a lucene 3.x

-Yonik
http://www.lucidimagination.com


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message