On 5/26/2016 2:37 AM, Nuhaa All Bakry wrote: > Wondering if versioning is built-in in Solr? Say I have deployed a working > SolrCloud (v1.0) and there are applications consuming the REST APIs. Is there > a way to deploy the next v1.1 without removing v1.0? The reason I ask is > because we dont want the deployment of Solr to be tightly dependent on the > deployment of the applications, or vice versa. > > I cant find a documentation on this (yet). Please share if you know where I > can read more about this.
In general, the Solr HTTP API does *not* change very much. Quite a lot of the HTTP API is dictated by solrconfig.xml, with recommendations in the examples, so it is frequently possible to make a new *major* version behave like the previous major version. Upgrading through two major versions might reveal differences that cannot be adjusted by configuration. The response formats (json, xml, javabin, etc) can accept a version parameter which can control aspects of that response format, and using an old version number can ensure compatibility with older code. New versions of the response formats are very rare, and many people use them without a version number and don't have any problems. If you are only using the HTTP API, then I would not be concerned too much about this when upgrading within a major version ... and your code may also work perfectly fine through a major version upgrade. There is one exception to what I said above: If you are using CloudSolrClient from SolrJ (or another cloud-aware client) to talk to your SolrCloud, then this is much more tightly coupled to the version, because CloudSolrClient talks to *zookeeper* (as well as using the HTTP API) and is strongly aware of SolrCloud internals. Mixing different SolrJ and Solr versions is discouraged when using CloudSolrClient, unless the version difference is very small and SolrJ is newer. The reason this can be a problem is that SolrCloud internals have been evolving *very* rapidly with each new release. Thanks, Shawn
