You update SAMSON, open a molecular project, and an extension you rely on is no longer available. It is tempting to focus on the extension’s own version number—but SAMSON uses a different version number to decide whether an extension can load: the version of the SDK used to build it.
Knowing which versions matter can make extension problems easier to understand and help you avoid assumptions when updating SAMSON or developing an extension.
Two version numbers, two different jobs
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 version is the release label you may recognize, while the internal version follows the major.minor.patch format.
An extension also has its own version number. Its developer can use that number to describe extension updates, but SAMSON does not use it to decide compatibility. For that decision, SAMSON compares its own version with the SDK version used to build the extension.
The practical compatibility check
According to the versioning guidance, the SDK and SAMSON must have the same major version, and the SDK minor version must be lower than SAMSON’s minor version. This reflects a common release concern: an extension built against a newer SDK may rely on functionality that an older SAMSON release does not have.
For example, an extension built with SDK 1.6.4 can load in SAMSON 1.7.8: the major versions match, and the SDK minor version is lower. But an extension built with SDK 1.8.5 is not compatible with SAMSON 1.7.8, because the SDK minor version is newer. The extension might depend on an API that SAMSON 1.7.8 does not provide.
A useful troubleshooting habit: when an extension does not load after a change, find out which SDK version was used to build it and compare that with SAMSON’s internal version. Do not rely only on the extension’s own version label. Also remember that compatibility is a necessary check, not a guarantee that every possible loading issue has the same cause.
One detail worth checking
The documentation’s compatibility rule says the SDK minor version must be lower, but its example also identifies SDK 1.7.7 as compatible with SAMSON 1.7.8, even though both have minor version 7. Because those statements do not match exactly, treat that boundary case with care: check the current compatibility guidance or test with the SAMSON version you plan to use rather than assuming the rule resolves it.
Why updates can affect extensions
SAMSON can automatically update extensions when compatible versions are available on SAMSON Connect and an internet connection is available. In the documentation’s example, SAMSON 1.7.8 can load an extension built with SDK 1.5.2, and can update it to a version built with SDK 1.6.4. If SAMSON later moves to a different major version, an extension built for that new major version will not be updated for a user who remains on 1.7.8.
The takeaway is simple: when planning an update or diagnosing a missing extension, check the SAMSON internal version and the extension’s build SDK version separately. That small check can help clarify whether the versions are compatible before you spend time investigating other causes.
For the full rules and examples, see the SAMSON versioning documentation.
Note: SAMSON and all SAMSON Extensions are free for non-commercial use. Get SAMSON.