: What about solr.xml and it is always there? A single core is just multicore : with one core. I know that one's been tossed around before. Of course, back : compat. gets in the way a bit.
Hence suggestion #1 -- things work exactly like they do today on the trunk, we just rename one file. : Also, maybe we should also mark multicore as experimental (starting to sound : like a lot of Solr is "experimental", these days, what w/ a good number of 1) I don't think that's neccessary, it sounds like a lot of people have been putting it through the paces. 2) I'm not sure what that would even mean ... marking a class or a method or a response format experimental i can understand but a broad feature like MultiCore? : To be honest, I really think we need to start thinking a lot harder about Solr : on Spring. All this config stuff just makes my head hurt. It can all be so : much simpler, IMO. In fact, part of me thinks 1.3 should be our last 1.x : release, but most of me knows that is not realistic. I think w/ Spring, we I don't really drink from the "Spring would solve all our config/init problems" Kool-Aid, but i don't disagree with you. My concern right now is making sure that 1.3 doesn't have a config file with a confusing name -- if we have more releases after 1.3 that use that our current config files before we get arround to switching to Spring based configuration, then that's all the more reason to get it right now -- but even if we said that we were 100% certain we were switching strategies in the next release, it still seems worthwhile to me to change the name for 1.3. : At any rate, that is a side decision. If we really are going to take on the : multicore issue, then we need to postpone the release, IMO. Otherwise, I : think we should just label it as it is expected to change in the next release. If we just rename the file, i really don't see it as being that big of a deal ... i suspect it could be done pretty easily without needing to delay the release. -Hoss
