Maintaining Rice Version Backwards Compatibility

Owned by Mary Northup
Last updated: Mar 22, 2013Version comment
1 min read

Maintaining Rice Version Backwards Compatibility

Summary

First, the purpose of version backwards compatibility is to allow the Central Rice server to upgrade without impacting the client applications (removing the need to coordinate upgrades across clients). Thus, the assumption is that the Client Applications will always be running either the same version of Rice or an older version but never will the Client Applications upgrade before the Central Rice server as this breaks the version compatibility rules.

The main requirement for the Rice client applications to maintain Rice version compatibility is that the client applications always include the version number for the version the imbedded Rice server is running when sending requests to the Central Rice server and when using the APIs/Framework to access the database directly.

When there are key database updates in a new version the client application must include the jars that match the version of the central Rice server so that the APIs/Framework modules used will be able to properly access the new information on the central Rice server database.

There are, of course, several details to actually implement this strategy.  The document below is a good starting point, but always consult the documentation available for the specific Rice version you are using. 

  

    Version Compatibility with Embedded Implementation
Embedded Rice is version 2.1.2, Rice Services is version 2.2.1
Embedded Rice will use 2.1.2.war and jars from 2.2.1 (in this case because of database changes).

Compatibility Information