Multi-version capability

[martinmcclure]

Currently, Sparkle depends on having identical versions of Sparkle installed in the GemStone server and the Pharo client. In a scenario where an organization has many stones running and many developers using Sparkle, this requirement could be difficult to satisfy. Add the likelihood that the stones will be of different versions and that different versions of Pharo could be in use by different developers, and using the same Sparkle code across an organization can easily become impossible. So...

Sparkle needs to support multiple Sparkle versions concurrently. The main pieces of this are

• Allow one Sparkle load support more than one version of remote Sparkle
• Provide a way for the client and server to negotiate a compatible version to use upon login.

To implement this:

• Use version-specific subclasses of presenters, RSR services, and tools so that all the code can coexist.
• Each release of Sparkle will also include code for some (not necessarily all) previous versions.
• Versions will be numbered with integers corresponding to Sparkle releases, starting with 1.
  • There will also be a pseudo-version "dev" for unreleased code.
• Upon connection, the server and client will negotiate a common version to use.
  • By default, the highest-numbered version the client and server have in common will be used.
  • There is also API to request a specific version, numbered or "dev."
  • If there are no versions in common between client and server, or an explicitly-requested version does not exist on both client and server, the connection is terminated with a version mismatch error.
  • Numbered versions should always functionally match. However, the "dev" version is a moving target, intended for use in the development and testing of Sparkle. The "dev" version should not be requested unless the requestor knows that the server and client code are identical.
• After connection, once a version is selected Sparkle will assemble the appropriate subclasses to be used for that connection.