Skip to content

releases.md

Latest commit

 

History

History
40 lines (26 loc) · 1.7 KB

releases.md

File metadata and controls

40 lines (26 loc) · 1.7 KB
Raw

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.