A SAMSON update can bring useful fixes and new capabilities, but it can also raise a practical question: will the extensions you rely on still load? This matters when an extension is part of a repeatable molecular modeling workflow. Understanding the version numbers behind SAMSON and its extensions can help you spot compatibility risks before they disrupt your work.
Two version numbers, two purposes
SAMSON uses a public version label, such as 2026 R1, and an internal version number for SAMSON and its Software Development Kit (SDK), such as 11.0.0. The public label identifies the release; the internal version is the one that matters when checking SDK compatibility. The current release described in the documentation is public version 2026 R1, internally based on SAMSON and SDK version 11.0.0.
Extensions also have their own version numbers, in the major.minor.patch format. That number can tell you which extension release you have, but SAMSON uses the SDK version that built the extension—not the extension’s own version—to decide whether it can load.
The compatibility rule to check
For an extension to be compatible, its SDK and SAMSON must have the same major version, and the SDK’s minor version must be lower than SAMSON’s minor version. In short:
- The major versions must match.
- The SDK minor version must be smaller than SAMSON’s minor version.
For example, SAMSON 1.7.8 can load extensions built with SDK versions 1.3.5 or 1.7.7. An extension built with SDK 1.8.5 is not compatible with SAMSON 1.7.8: it may depend on functionality that the older SAMSON release does not have. A different major version also means the versions are incompatible.
One detail worth noticing: the documented rule compares the major and minor numbers. It does not say that a matching patch number makes an otherwise incompatible pair compatible. Don’t infer compatibility from similar-looking version strings alone.
A simple check before changing versions
- Find the internal SAMSON version. Don’t use the public release label as a substitute; the documentation’s current example maps 2026 R1 to internal version
11.0.0. - Check the SDK version used to build an extension. This is the version relevant to SAMSON’s compatibility check.
- Compare major and minor numbers. Confirm the majors match and the SDK minor is lower than SAMSON’s minor.
- Consider the version change before upgrading. A SAMSON release with a different major version will not meet the compatibility rule for an extension built against the previous major.
As a practical workflow, note the SAMSON and SDK versions associated with extensions that are important to a project. When planning an update, check whether compatible extension versions are available, and test a key workflow after updating. This is especially helpful if an extension supports a step you need to repeat or reproduce.
What automatic extension updates do—and don’t do
SAMSON can automatically update extensions at startup when a newer compatible version is available on SAMSON Connect and an internet connection is available. For instance, with SAMSON 1.7.8, an extension built with SDK 1.5.2 can load; a newer extension built with SDK 1.6.4 can also be compatible and updated automatically. But if SAMSON stays at 1.7.8 and an extension update is built with SDK 2.0.0, SAMSON will not install that incompatible update. Automatic updates help keep compatible extensions current; they do not remove the version compatibility requirement.
For the full versioning rules and examples, read the SAMSON versioning documentation.
Note: SAMSON and all SAMSON Extensions are free for non-commercial use. Get SAMSON.