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
