# Releases

`dify-aio` uses upstream-version-plus-AIO-revision releases such as `1.14.0-aio.1`.

## Version Format

- first wrapper release for upstream `1.14.0`: `1.14.0-aio.1`
- second wrapper-only release on the same upstream: `1.14.0-aio.2`
- first wrapper release after upgrading upstream again: `vX.Y.Z-aio.1`

## Published Image Tags

Every central `aio-fleet` publish for `main` publishes:

- `latest`
- the exact pinned upstream Dify version
- `sha-<commit>`

Release commits also publish the exact immutable release package tag, for example `1.14.0-aio.1`. Ordinary `main` pushes do not overwrite that release tag.

## What A Dify AIO Release Means

A release means the wrapper has been validated against a specific upstream Dify version and its companion images:

- `langgenius/dify-api`
- `langgenius/dify-web`
- `langgenius/dify-sandbox`
- `langgenius/dify-plugin-daemon`

## Release Flow

1. From `aio-fleet`, run `python -m aio_fleet release status --repo dify-aio` to inspect the next release.
2. Run `python -m aio_fleet release prepare --repo dify-aio` on a release branch, then open a `chore(release): <version>` PR.
3. Review and merge that PR into `main`.
4. Run the central `aio-fleet` control check for the release target commit with publish enabled, and require `aio-fleet / required` to pass.
5. Run `python -m aio_fleet release publish --repo dify-aio` from `aio-fleet` to create the GitHub Release.

## Deep Provider Validation

The normal release path requires the standard integration suite. Run the manual extended integration suite before Community Applications submission, before large Dify upstream jumps, or when changing database, Redis, vector, storage, mail, plugin, or observability configuration behavior.