> > : We're jumping to version 3.1 because we're releasing at the same time, > : and are based on Lucene 3.1. > > You say it like it's a done deal, but I don't get the impression > that i'm the only one who thinks it's unneccessary.
+1, I'm right there with you on this Hoss. > > My point is really simple: Even if we release at the same time, and even > if we're using Lucene-Java 3.1, that doesn't mean the solr release artifact > *needs* to be called solr-3.1. > > the only "pro" i've seen suggested (over and over) is that it makes the > solr version number consistent with the luene-java version -- but the > "con" is that it's inconsistent with past versions of solr. Exactly. > Since more > Solr users (should) have never known nor cared about the lucene-Java > version used under the hood, being consistent with past solr versioning > seems more useful then being consistent with the versioning of something > internal. Agreed. > > hardcore users who are writing really low level plugins and interacting > directly with the LUcnee-Java APIs inside Solr will care what > version of LUcene-java is being used under the covers, but hey can get > that from the release notes, it doesn't need to be advertised in the > artifact name (2.0 will significantly advertise "this is a big change, > plugins will break") > > I just don't see how jumping to solr-3.1 is any more useful to the users > then jumping to solr-2.0; it certinaly seems more confusing. +1 on that. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
