: > 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. : : To try and put it simply - w/o an attempt at synchronized releases, : I'm against of code/modules moving out of solr. It get's to the heart : of why we merged in the first place.
Hmmm, i'm not sure what to say about that. My recollection of the discussion was that almost everyone agreed that refactoring and reducing code overlap was a good idea, but synchronized releases seemed to be the biggest sticking point people had (isn't that why there was a second (or maybe third?) "take" on the vote ... to remove that item?) In any case: it's still orthogonal to the point i'm trying to make Even if Lucene-Java, and Solr, and a bunch of new modules refactored out of the two, all start getting lock step releases, the version labels we put on those releasees shouldn't neccessarily be identical. We could easily find ourselves in either of the following two situations for any arbitrary release off the "trunk" (assume it's 2011-05-23, and the last release of both Lucene-Java and Solr was known as version "4.2") 1) Lucene-Java has made some massive public API changes that included removing some deprecated APIs because they were horribly broken and could corrupt data - so people agree that the version number should be bumped to "5.0"; Solr has never used the old buggy API, and does not expose any of the new underlying API changes, and has had very few changes since 4.2 ... reving up to "5.0" would give users the impression that something significant had changed, when in fact very little has changed. 2) Solr has made some major front end API changes and removed some deprecated RequestHandlers that were buggy, so Solr really needs to bump the version number up to "5.0"; Lucene-Java has made some very minor feature additions, and the trunk is 100% back compat with 4.2 -- calling it "lucene-Java 5.0" would give people a missleading ipression that it was not API compatible with the previous release. My key point being: Version numbers should communicate the significance in change to the *user* of the product, and the users of Solr are differnet then the users of Lucene-Java, so even if the releases happen in lock step, that doesn't mean the verion numbers should be in lock step. -Hoss
