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.7.2) and the most recent minor release (e.g., 3.7.0), but does not guarantee source-code compatibility between minor releases (e.g., between 3.6 and 3.7).

Upgrading your Application to Ice 3.7.2 from Ice 3.6 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 "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. 

The Ice message format is governed by two sets of rules: the protocol rules and the encoding rules. The protocol rules define the number of message types as well as the format of the message headers. The encoding rules specify how Slice types are marshaled. Ice maintains separate versions for the protocol and encoding, which makes it possible for them to evolve independently.

Several features introduced in Ice 3.5 required changes to the way that Slice classes and exceptions are marshaled. These changes make the encoding incompatible with previous releases, and therefore Ice 3.5 introduced version 1.1 of the Ice encoding. No additional encoding changes were made in Ice 3.6 and Ice 3.7.

The protocol remains the same since the first version Ice, with protocol version number 1.0.

Changing the protocol or encoding format can be disruptive and does not happen often. Naturally, these changes raise the issue of backward compatibility with applications that use earlier versions of Ice, and more specifically, applications that use version 1.0 of the Ice encoding. Ice 3.5, 3.6 and 3.7 use the following semantics:

• Encoding version 1.1 is the default for these releases. You can change this default using the Ice.Default.*