A modeling workflow can depend on a SAMSON Extension for a particular task, so discovering that the Extension will not load—or has not updated—can be frustrating. The version numbers offer a useful first check, but SAMSON uses more than one kind of version number. Knowing which one matters can save time and help you distinguish an Extension update issue from a SAMSON update issue.
Start by separating the version numbers
SAMSON has a public release label and an internal version number. For example, the documentation identifies the public release as 2026 R1, based internally on SAMSON and its Software Development Kit (SDK) version 11.0.0. The public label tells you which release you are using; the internal version is the one relevant to the SDK compatibility rules described here.
Extensions also have their own version numbers, in the format major.minor.patch. That number can tell you that the Extension itself has changed, but it is not the number SAMSON uses to decide whether the Extension can load. For that decision, SAMSON checks the SDK version used to build the Extension.
What SAMSON checks at startup
When SAMSON starts, it compares its version with the SDK version used to build each installed Extension. According to the documented compatibility rule, the two major version numbers must match, and the SDK minor version must be smaller than SAMSON’s minor version. The patch numbers do not appear in that compatibility test.
For example, the documentation describes an Extension built with SDK 1.5.2 loading in SAMSON 1.7.8: the major versions match, and the SDK minor version is lower. An Extension built with a different major version does not meet the stated rule. Likewise, an Extension built against a newer SDK minor version may rely on functionality that an older SAMSON release does not have.
This is why an Extension’s own version number is not enough to diagnose a loading problem. A newer Extension release may still be incompatible with the SAMSON version installed on your computer, while an older Extension release may remain compatible.
A practical check when an Extension is missing
- Check SAMSON’s internal version. Do not compare only the public release label, such as
2026 R1. - Find the SDK version used to build the Extension. This is the version relevant to SAMSON’s compatibility check.
- Compare the major and minor numbers. The major versions must match, and the SDK minor version must be lower than SAMSON’s under the documented rule.
- Consider whether SAMSON has been updated. An Extension built for a newer SDK may need a newer SAMSON release before it can load.
This check helps explain why simply reinstalling an Extension or looking at its own release number may not solve the problem. The key question is whether its build SDK is compatible with the SAMSON version you are running.
Why an Extension may not update automatically
SAMSON can automatically update Extensions when compatible versions are available on SAMSON Connect and an Internet connection is available. Compatibility still matters: an Extension release built with an SDK that is not compatible with your installed SAMSON version will not be installed as an update. The existing compatible version can remain in place instead.
In the documentation’s example, SAMSON 1.7.8 can load an Extension built with SDK 1.5.2. If a compatible release built with SDK 1.6.4 becomes available, SAMSON can update the Extension at startup. But if SAMSON moves to version 2.0.0 and the user stays on 1.7.8, an Extension release built for SDK 2.0.0 will not replace the compatible older Extension.
The practical takeaway is straightforward: when an Extension does not load or update, check the SDK version it was built with and the internal SAMSON version first. Updating SAMSON can make newer compatible Extension releases available; the Extension’s own version number alone cannot establish compatibility.
Learn more about SAMSON versioning and Extension compatibility in the documentation.
Note: SAMSON and all SAMSON Extensions are free for non-commercial use. Get SAMSON.