I recently had an IRC conversation about Solr 4.0. The main question that the person who was chatting with me had was “How far out is the 4.0 release?” The answer, as with almost any open source project, is “when its released.”
Naturally, that answer doesnt really help get to the crux of what most IT teams who either use or are considering Solr need to figure out, which is whether 4.0 is stable enough to deploy in a live environment.
Solr, even in unrelated versions, has historically been pretty stable. So, if a new version, in this case 4.0, has the functions that youre looking for – in this conversation, it was function queries like idf() or termfreq() – then unless youre comfortable with compiling a previous version of Solr and creating your own code on top of it, then youre probably going to want to go with the latest version.
Of course, this approach does come with risk. I have only heard of 1 actual “bug” that led to incorrect/wrong results sneaking into the Solr code base in an unreleased project, and it was quickly found and fixed. But, since youre working on a code base which may change somewhat, if you are building indexes that you can not easily rebuild, for example, indexing the Internet and cant recrawl to generate the data – meaning if Solr is your “system of record”, then be aware that over time the index file format may change because Lucene is changing under the covers and periodically there is an email that tells you that you need to rebuild your indexes. But, if you are basically taking a download of Solr 4.0 as it is today, and then only going to update a) when new killer awesome feature added or b) when 4.0 comes out, then reindexing shouldnt be a problem.
The other aspect of deploying Solr 4.0 is your testing environment. If you have strong system and functional testing, then you can be fairly sure that things are working appropriately. If youre not certain about testing, check out my presentation on Better Search Engine Testing from this years Software Test and Performance Conference.