Page History

Geode supports rolling upgrade between both major and minor versions.  This means that we support shutting down locators one-by-one and restarting them with the new version, followed by doing the same with servers.  New clients are not allowed to run against old servers, so clients either remain using old versions or are rolled forward after locators and servers are using the new version.

...

String currentVersion = VersionManager.CURRENT_VERSION;

...

Tests can be parameterized to be run with multiple versions.  An example of this is ClientServerMiscBCDUnitTest, which subclasses an existing test to run with mixed versions.  Its superclass was modified to run servers with the current version while clients are run with either the same or a different version.  The subclass then iterates through available "old versions" to test that old-version clients function correctly with servers using the new version of Geode.

...

 host.getVM(testVersion, 0).invoke(() -> this.createClientCacheV(serverName, port1));

The subclass then uses a parameterized junit runner class:

...

    testVersion = version;

  }

...

Note that the category BackwardCompatibilityTest was added to the subclass so that all BC tests can be run as a unit if desired.

...

Internals note: Old versions are defined as source-sets in the geode-old-versions module.  Versions are denoted by the name of the source-set minus the leading "test" in its name, so that test100 translates to version "100" in VersionManager.   These do not translate directly into Geode version ordinals.  If you need to know the exact version a VM is running you can invoke code to look at Version.CURRENT in the VM in question. In general these will be as you'd expect: "1.0.0-incubating", "1.1.0", "1.2.0", etc.  These correspond to downloadable Geode releases.  To find the actual release being used in a VM you can invoke GemFireVersion.getGemFireVersion().