I note with interest that the Apache Lucene community has recently decided to merge the development of two of its best-known sub-projects: Lucene->Java and Lucene->Solr. As a result, both code bases now sit under the same trunk in SVN and Solr runs off the latest Lucene code at all times. Release artifacts will remain separate: Lucene remains a core search engine Java library and Solr will remain a search server built on top of Lucene.
So why the change? The way things worked in the past, with many overlapping committers, quite a few features that could have benefitted Lucene ended up being placed in Solr. Such features may have “belonged” in Lucene, but due to dev issues, it was often best for Solr to keep certain features that were contributed by Solr developers under Solr’s control. If some of this code were moved to Lucene it could mean that a Solr committer who wrote and committed the code might actually lose the ability to maintain it without the assistance of a Lucene committer, and meanwhile, there could be long waits for Lucene bug fixes to be available in Solr trunk.
With merged dev, there is now a single set of committers across both projects. Everyone in both communities can now drive releases (so when Solr releases, Lucene will also release), hence no more concerns about having to sometimes release Solr on a "development" version of Lucene. Now Solr will always be on the latest trunk version of Lucene. Also, Lucene benefits from greater test coverage, as now a developer can make a single change in Lucene and run tests for both projects.
No matter how you look at it, it's a win-win situation -- one that probably should have happened sooner (but hey, better late than never).
