GemStone / Gt4GemStone / GT Version Management

This page describes the philosophy and reasoning behind the adopted approach to managing various combinations of GT, Gt4GemStone & GemStone.

The assumption is that the GemStone server will move much more slowly than GT (and Gt4GemStone).

Given the above assumption, it is up to GT (and the GT4GemStone client) to work with whatever version of the GemStone server is presented.

As such, the GemStone server won't have any version management / backward compatibility in it. It will just operate with the latest version.

GT communicates with GemStone using GemStone Remote Service Replication (RSR), which can be split in to two areas:

1. Service class definition.

The shared service class definition must be the same on both GT and GemStone. Any change in the definition will require a new version of the service.

2. Service method calls.

Since the GemStone server isn't responsible for any version management, it will implement the functionality directly in the Server service object.

In GT, all communications go through the GtRsrEvaluatorServiceClient GtRsrEvaluatorService subclass: #GtRsrEvaluatorServiceClient instanceVariableNames: 'gtSession versionedEvaluator' classVariableNames: '' package: 'GToolkit-GemStone-Pharo-Services' , which delegates all operations through a GtRsrVersionedEvaluator. Selection of the appropriate GtRsrVersionedEvaluator is based on the version number, not class name.