--- schema_version: "1" id: 11f0c4f9a0c0064ad161e5976a682539e6766d81c0334dd00b00073f5225c61e title: Managing Asset Lifecycle States collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/exchange/lifecycle.md canonical_url: https://docs.mulesoft.com/exchange/lifecycle source_site: docs.mulesoft.com content_type: documentation content_hash: fa13a549c5c7fa7797f1d2684fcda00f0051998ec37c186c591b60d917f3f9d0 description: MuleSoft Documentation Site latest: true --- --- product: Exchange --- # Managing Asset Lifecycle States > For the full documentation index, see: https://docs.mulesoft.com/llms.txt In the software development lifecycle, assets are developed, released, and eventually deprecated, and each Exchange asset version moves through the lifecycle states of `development`, `stable`, and `deprecated`. ## Development State An asset version in the `development` state is in an iterative process of design and development. If you republish an asset version in the `development` state with the same groupId, assetId, and version (GAV) and new metadata, the asset version is overwritten, including the following version metadata: - Files - Dependencies - Keywords Changing this information for an asset version in any other state requires creating a new version, which prevents republishing or overwriting the asset version. Overwriting an asset version also updates the search index. The following information is not overwritten when republishing an asset in the development state: - Asset type - Tags - Categories - Custom fields - Documentation pages Deleting an asset version in the `development` state is always a hard delete, enabling you to reuse the asset’s name, groupId, assetId, and version. The public portal does not show asset versions in the `development` state. Anypoint Platform products other than Exchange, such as Anypoint Studio, API Manager, or Anypoint DataGraph do not consume asset versions in the `development` state. ## Stable State An asset version in the `stable` state is ready to be consumed. The asset cannot be republished or overwritten. Deleting an asset version in the `stable` state in the first seven days is a hard delete, enabling you to reuse the asset’s name, groupId, assetId, and version. Deleting an asset version in the `stable` state after the first seven days is a soft delete, preventing you from reusing the asset’s name, groupId, assetId, and version. After a hard delete or a soft delete, an asset cannot be recovered. The Exchange backend and some API responses use the term `published` to mean `stable`. ## Deprecated State An asset version in the `deprecated` state is similar to an asset version in the `stable` state. The only difference is that the `status` property shows the asset version is deprecated. ## Create an Asset in the Exchange User Interface 1. Click **Publish new asset**. 2. Set **Lifecycle state** to the **Development** state or the default **Stable** state. 3. Set other asset information. 4. Click **Publish**. ## State Promotion These are the three possible state promotions: 1. `development` to `stable` 2. `stable` to `deprecated` 3. `deprecated` to `stable` Only Administrators can promote an asset to development, stable, and deprecated states. Contributors can only promote an asset to development and stable. Promote an asset version’s state either in the asset’s Exchange portal or by using the Exchange API. In the asset’s documentation page, click the lifecycle state button that displays the current state, and select the new state of **Development**, **Stable**, or **Deprecated**. To use the Exchange API, follow the [Promote Lifecycle State](https://docs.mulesoft.com/exchange/exchange-api#promote-lifecycle-state) example. ## State Dependencies An asset in the `stable` state cannot add an asset in the `development` state as a dependency. If an asset in the `development` state depends on one or more other assets in the `development` state, Exchange does not allow promoting that asset to the `stable` state. All dependencies of the asset should be promoted to stable first. If an asset in the `development` state has dependencies in `development` state and the dependent is modified, the dependent asset is also not regenerated. It is the asset owner’s responsibility to republish the dependent asset once its dependencies are updated. ## Create an Asset Using the Exchange API To create an asset using the Exchange API, follow the [Set Lifecycle State](https://docs.mulesoft.com/exchange/exchange-api#set-lifecycle-state) example. ## Create an Asset Using Maven To create an asset using the Exchange Maven Facade API, follow the [Asset Lifecycle State](https://docs.mulesoft.com/exchange/to-publish-assets-maven#asset-lifecycle-state) example. ## Search Using the Graph API by Lifecycle State To consume an asset and its lifecycle state, or to search for an asset by lifecycle state, follow the [Asset Lifecycle State](https://docs.mulesoft.com/exchange/to-search-with-graph-api#asset-lifecycle-state) examples. ## See Also - [Delete an Asset](https://docs.mulesoft.com/exchange/to-delete-asset) - [Publish Assets Using the Exchange API](https://docs.mulesoft.com/exchange/exchange-api) - [Publish Assets Using Maven](https://docs.mulesoft.com/exchange/to-publish-assets-maven) - [Search Using the Graph API](https://docs.mulesoft.com/exchange/to-search-with-graph-api) - [Graph API Web Interface](https://anypoint.mulesoft.com/graph/api/v2/graphql)