A SAMSON Extension that worked yesterday may fail to load after a software update—or may not update when you expect it to. For molecular modelers, that can interrupt a workflow at exactly the wrong moment. The useful clue is that SAMSON tracks more than one kind of version, and an Extension’s own version number is not the same thing as the SDK version used to build it.
Here is a practical way to interpret the numbers before troubleshooting or planning an update.
First, distinguish the two SAMSON versions
SAMSON has a public version, such as 2026 R1, and an internal version shared by SAMSON and its Software Development Kit (SDK), such as 11.0.0. The public label helps identify a release; the internal major.minor.patch number is used for compatibility rules. The documentation identifies 2026 R1 as internally based on SAMSON and SDK version 11.0.0.
So if you are checking whether an Extension can run, do not compare its public-facing release label with an Extension version. Look for the SDK version used to build the Extension and compare it with the internal SAMSON version.
The compatibility check, in plain language
At startup, SAMSON checks the SDK version associated with each Extension. According to the documented rule, an SDK version is compatible with a SAMSON version when:
- Their major version numbers are identical.
- The SDK’s minor version number is smaller than SAMSON’s minor version number.
For example, with SAMSON 1.7.8, an Extension built with SDK 1.6.4 satisfies both conditions: the major numbers match, and the SDK minor number is lower. An Extension built with SDK 2.0.0 does not satisfy the major-version condition. A different major number is a clear sign that you should not expect that build to load in the installed SAMSON version.
The patch number still matters as part of the full version identifier, but the compatibility criteria described here are based on the major and minor numbers. In practice, keep the complete SDK version available when reporting a loading problem; it is more useful than an Extension’s display name or its own release number.
Why an Extension may not update
SAMSON can automatically update Extensions when a newer compatible build is available on SAMSON Connect and an Internet connection is available. Compatibility limits which build can be installed: automatic updates do not make a build for a different major version usable in an older SAMSON installation.
For instance, the documentation describes a user on SAMSON 1.7.8 with an Extension built using SDK 1.6.4. If a new Extension build is published for SDK 2.0.0, a user who remains on SAMSON 1.7.8 will keep the compatible 1.6.4-built Extension rather than receive the incompatible newer build. Updating SAMSON may therefore be part of resolving an Extension update gap.
A quick troubleshooting checklist
- Check the installed SAMSON internal version, not just its public release name.
- Find the SDK version used to build the Extension.
- Compare the major numbers, then check whether the SDK minor number is lower than SAMSON’s.
- If a newer Extension build is missing, confirm that SAMSON is current and that an Internet connection is available.
- Do not assume an Extension’s own
major.minor.patchrelease number determines whether it loads. SAMSON uses the SDK version for that compatibility decision.
One additional detail: during the beta period, when the major version is zero, the minor and patch numbers have adjusted roles in the versioning policy. If you are working with a beta release, consult the versioning rules rather than applying the stable-release interpretation automatically.
Understanding these distinctions can save time when an Extension does not load or update: the issue may be a version mismatch, not a problem with your molecular model. For the full rules and examples, read the SAMSON versioning documentation.
Note: SAMSON and all SAMSON Extensions are free for non-commercial use. Get SAMSON.