---
schema_version: "1"
id: f4a7d5234f4832183f74a5fdb33304af4d71c85b4279452b4a35f0b230d2dd59
title: Extensions API (Deprecated)
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-sdk/latest/extensions-api-deprecated.md
canonical_url: https://docs.mulesoft.com/mule-sdk/latest/extensions-api-deprecated
source_site: docs.mulesoft.com
content_type: documentation
content_hash: ff9d28b333cca550c0300f8bd6c27f5c6a0e3c6c53c3d541bc1b973adfa20560
description: MuleSoft Documentation Site
release: "1.13"
latest: true
---
---
product: Mule SDK
version: 1.13
is-latest-version: true
keywords: mule, sdk, extensions api, deprecated, legacy
---

# Extensions API (Deprecated)

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

This page documents the legacy approach to SDK versioning using `mule-modules-parent`. For new
modules, see [Forward Compatibility](https://docs.mulesoft.com/mule-sdk/latest/forward-compatibility) with `mule-java-extension-parent`
instead.

In traditional SDK development, the SDK version is tightly coupled to the Mule runtime engine
version. When you develop with the SDK, you use the Extensions API. Whenever you annotate a field or
method with SDK annotations, or implement any interface, you are using parts of this Extensions API.

The module you ship contains only your code. The Extensions API implementation in the runtime
bridges the gap between your module and the Mule runtime internals.

## SDK Version and Mule Runtime Compatibility

Each Mule runtime version ships with support for one particular version of the Extensions API, plus
all previous versions.

For example:

- Mule `4.1` ships with SDK version `1.1`

- Mule `4.2` ships with SDK version `1.2`

Mule `4.2` fully supports modules developed with SDK versions `1.2`, `1.1`, and `1.0`. However, a
module built with SDK `1.2` requires at least Mule `4.2`, it won’t work in Mule `4.1`.

This concept works both ways:

- Any Mule runtime version supports all earlier SDK versions, so a module built for Mule `4.1` works
  with any later Mule 4.x version

- If a module is built using SDK `1.2`, it only works in runtimes that support that SDK version

## Choosing a Version

When using the legacy approach, use the oldest SDK version that includes all the features you need:

- If you need only basic connectivity and DataSense, use version `1.0`

- If you need `PollingSource`, use SDK `1.1` which introduced that feature

This ensures your module is compatible with the widest range of Mule runtime versions.

## Change the Version

The SDK version is specified in the `parent` element of your `pom.xml`:

```xml
<parent>
  <groupId>org.mule.extensions</groupId>
  <artifactId>mule-modules-parent</artifactId>
  <version>1.9.0</version>
</parent>
```

To change versions, update the `<version>` in the parent element. Choose the `mule-modules-parent`
version that corresponds to your target Mule runtime version.

## Bug Fixes

The Extensions API implementation resides in Mule runtime, so most SDK-related bug fixes are
released in patch releases and service packs for Mule, not through new SDK versions.

In some cases where the issue is in the API definition, a patch release of the SDK is made available
(for example, `1.1.2`). Always choose the higher bug fix version—between `1.0.0` and `1.0.4`, pick
`1.0.4`.

## See Also

- [SDK Forward Compatibility](https://docs.mulesoft.com/mule-sdk/latest/forward-compatibility)

- [Choosing the SDK Version](https://docs.mulesoft.com/mule-sdk/latest/choosing-version)