Choosing the SDK Version
Developers tend to use the latest available version of a given product. This should not be the case with the Mule SDK. When choosing a version of the SDK to use for extending a Mule module, you should:
Identify the features you need.
Choose the lowest version that includes the features you need.
The next sections explain why.
When you are developing with the SDK, you are really using an API, the Extensions API. Whenever you annotate a field or method with any of the SDK annotations, or when you implement any interface, you are simply using parts of this Extensions API. The module that you ship only contains your code. It does not contain any of the code that bridges your module with the Mule Runtime internals. This gap is bridged in the Runtime because of the
Each version of the Mule Runtime ships with support to one particular version of the
Extensions API, plus all the version that proceeded it
For example, assume that both are true:
4.1ships with SDK version
4.2ships with SDK version
4.2 will fully support any module developed with SDK versions
1.0. If Mule
4.3 introduces SDK 1.3, it will also support
1.1, and so on.
This concept works both ways:
Any Mule Runtime version will support all the SDK versions that were released before, so a module that works in Mule
4.1should work in any Mule 4.x (where
x >= 1).
If a module is built using SDK
1.2, it will only work in runtimes that support that SDK version. In the case of this example, this module will not work in Mule
You should not aim to use the latest SDK version available because your module will only be compatible with the latest Mule Runtime. Instead, you should use the oldest version that includes all the features you need, for example:
If you are creating a simple connector that only needs connectivity and basic DataSense, you should use version
If you also need to use the
PollingSourceinterface, then use SDK 1.1, which introduced support for
PollingSource. Only the runtimes that support that feature will be able to run your module.
For any new SDK feature, the documentation includes the version in which it was introduced. If no particular version is specified, the feature has been present since the very first version.
The recommended approach is to start all your projects using version
Following these guidelines will make your module compatible with a wider number of Mule Runtime versions, so more people will be able to use your module. If you do not require features from newer versions, then there is no good reason for you to use the newer versions.
Extensions API is an API, and its implementation resides in the Mule Runtime, so most SDK-related bug fixes will be released in patch releases and service packs for the Mule Runtime, not through new SDK versions.
In some corner cases, where the issue is in the API definition, a patch release of the SDK will be made available (for example,
1.1.2). You should always choose the higher bug fix version. For example, between
1.0.4, you should pick
Note that version numbers mentioned above meant as examples that do not necessarily represent any existing versions or patches.
version is specified in your
pom.xml file of your module project, inside the
<parent> <groupId>org.mule.extensions</groupId> <artifactId>mule-modules-parent</artifactId> <version>1.1.6</version> </parent>
To change to another version, you simply change the parent version.