Of course consumability (good APIs) is important, but rational people can disagree when it comes to the specifics... many things come with tradeoffs.
Even non-API changes have tradeoffs... the indexing improvements (err, total rewrite) made that code *much* harder to understand and debug. It's a net win since the indexing performance improvements were so fantastic. Deprecating an existing class that's been around for a while simply for the purposes of slightly improving the naming.... may not be worth it (it's destroying a little piece of the collective memory of all developers who have used Lucene). Avoiding having to specify the type of a sort... I'm skeptical about the benefits vs potentially decreased flexibility and increased code size and complexity - but it's all hypothetical at this point. But on a positive note, Lucene 2.9 looks like it's suddenly progressing fast enough that it's feasible to use it in Solr 1.4 (which I've lobbied for in Solr-land) - which seems like it would be a win for both Lucene and Solr. -Yonik http://www.lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
