I do think major versions should be able to read the previous version index. Still, even being able to do that is no guarantee that it will produce correct results. Likewise, even having an upgrade tool is no guarantee that correct results will be produced. So, my take is that we strive for it, but we all have to realize, and document, that it might not always be possible. Let's just be practical and pragmatic. Past history indicates we are capable of, for the most part, reading the prev. version index and upgrading it. If it can't be done automatically, then we can consider a tool. If the tool won't work, then we will have to reindex. It doesn't have to be an all or nothing decision made in the void. We've always been very practical here about making decisions on problems that are directly facing us, so I would suggest we move forward with the new approach (which I agree makes more sense and is pretty prevalent across a lot of projects) and we take this issue on a case-by-case basis.
-Grant On Apr 15, 2010, at 9:49 AM, Yonik Seeley wrote: > On Thu, Apr 15, 2010 at 9:39 AM, Earwin Burrfoot <ear...@gmail.com> wrote: >> On Thu, Apr 15, 2010 at 17:17, Yonik Seeley <yo...@lucidimagination.com> >> wrote: >>> Seamless online upgrades have their place too... say you are upgrading >>> one server at a time in a cluster. >> >> Nothing here that can't be solved with an upgrade tool. Down one >> server, upgrade index, upgrade sofware, up. > > It's still harder. Consider a common scenario where you have one > master and the index being replicated to multiple slaves. One would > need to stop replication to an upgraded slave until the master is also > upgraded. Some people can't even stop replication because they use > something like a SAN to share the index. > > I'm just pointing out that there is a lot of value for many people to > back compatible indexes... I'm not trying to make any points about > when that back combat should be broken. > > -Yonik > Apache Lucene Eurocon 2010 > 18-21 May 2010 | Prague > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
