On Wed, Mar 17, 2010 at 8:15 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : > 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?)
Most people were on board with synchronized releases. Some people were treating it like a hard'n'fast contract forever... so Mike added a second vote that added an "out" to address that: * Release details will be decided by dev community, but, Lucene may release without Solr. The meaning, which most of us took (and expressed in the first vote thread), that the idea was that we would try to release at the same time, but lucene could still release if solr was clearly not ready. It certainly wouldn't be the norm though. In the interest of moving forward, perhaps we should just focus on the immediate next major release - 3.1. What happens after can wait. We never planned for absolutely all the "what if's" in Solr before the merge - I'm not sure why we would need to now. -Yonik
