The subsections below describe how Ice maintains (or does not maintain) backwards compatibility between versions.

On this page:

Source-code compatibility

Ice maintains source-code compatibility between a patch release (e.g., 3.6.1) and the most recent minor release (e.g., 3.6.0), but does not guarantee source-code compatibility between minor releases (e.g., between 3.5 and 3.6).

Upgrading your Application from Ice 3.5 describes the significant API changes in this release that may impact source-code compatibility. Furthermore, the subsections Removed APIs and Deprecated APIs summarize additional changes to Ice APIs that could affect your application.

Binary compatibility

As for source-code compatibility, Ice maintains backward binary compatibility between a patch release and the most recent minor release, but does not guarantee binary compatibility between minor releases.

The requirements for upgrading to a new minor (or major) release depend on the language mapping used by your application:

• For statically-typed languages (C++, Java, .NET), the application must be recompiled.

• For scripting languages that use static translation, your Slice files must be recompiled.

• No action is necessary for a Python or Ruby script that loads its Slice files dynamically.

On-the-wire compatibility

Ice always maintains protocol ("on the wire") compatibility with prior releases. A client using Ice version x can communicate with a server using Ice version y and vice versa. 

Several features introduced in Ice 3.5 require a new version of the Ice encoding, encoding version 1.1. Older versions of Ice do not understand this encoding: you need to use Ice encoding version 1.0 for communications between clients or servers using Ice 3.5 or later and clients and servers using older Ice versions. See Encoding Version 1.1 for details.

No additional encoding changes were made in Ice 3.6.

Database compatibility

Upgrading to a new minor release of Ice often includes an upgrade to the supported version of Berkeley DB. In turn, this may require an application to migrate its databases, either because the format of Berkeley DB's database files has changed, or due to a change in the schema of the data stored in those databases.

For example, if your application uses Freeze, it may be necessary for you to migrate your databases even if your schema has not changed.

Certain Ice services also use Freeze in their implementation. If your application uses these services (IceGrid and IceStorm), it may be necessary for you to migrate their databases as well.

Please refer to the relevant subsections below for migration instructions.

Interface compatibility

Although Ice always maintains compatibility at the protocol level, changing Slice definitions can also lead to incompatibilities. As a result, Ice maintains interface compatibility between a patch release and the most recent minor release, but does not guarantee compatibility between minor releases.

This issue is particularly relevant if your application uses Ice services such as IceGrid or IceStorm, as a change to an interface in one of these services may adversely affect your application.

Interface changes in an Ice service can also impact compatibility with its administrative tools, which means it may not be possible to administer an Ice 3.6.x service using a tool from a previous minor release (or vice-versa).

IceGrid

Starting with Ice 3.2.0, IceGrid registries and nodes are interface-compatible. For example, you can use an IceGrid node from Ice 3.2 with a registry from Ice 3.4.

IceGrid registry replication is only supported between registries using Ice 3.3 or later. Since the IceGrid database format changed in Ice 3.5, an IceGrid slave from Ice 3.4 or 3.3 will not be able to synchronize with an IceGrid master from Ice 3.5 or later. You need to upgrade all your IceGrid registries to Ice 3.5 or later to ensure replication between the registries work.

An IceGrid node using Ice 3.5 or later is able to activate a server that uses earlier Ice releases.

Regarding the IceGrid graphical and command-line administrative tools, you must use the 3.6 administrative tools to administer an IceGrid 3.6 registry; you cannot use an administrative tool from an earlier Ice version. The reverse is also true: you cannot administer an IceGrid 3.5 registry with an IceGrid 3.6 administration tool.

IceStorm

Topic linking is supported between all IceStorm versions released after 3.0.0.