: We try not to do that then. Things make a lot more sense when one : starts thinking of them as a single project, w/o multiple downloads. : : If major modules were to be pulled from Solr and put into Lucene, and : Solr wanted to make some big changes for a major version number bump? : How could it do so w/o lucene doing that? It's the same issue.
No, actaully it's the converse issue -- if a major piece moves from "solr" to "core" and a *person* wanted to make a major change to that piece of functionality that wasn't backwards compatible, then "core" would certianly need to undergo a major version bump. But the way that changes is made may not have any impact on how that functionality is ultimately exposed in Solr -- the "core" user based is all JAva developers who care a lot about the Java API -- the "solr" user based are typically not Java users, and have very little concern for what the Java internals look like -- in every release Solr has changed internal APIs in a way that was deeemed small enough to be acceptable to the (small) percentage of the user population that writes plugins, but those same changes in Lucene-Java would have mandated a major version change. The main issue i'm trying to raise is the opposite of your example: when a committer wants to make a big change to solr (frontend) code which will have a big impact on how users interact with Solr, but in no way shape or form affects the lucene core Java API ... how does that fit into a "lock step" version policy? -Hoss
