This repository uses a one-active-release workflow:
mainalways contains the current working release.- each shipped release is preserved in an
rhdh-x.x-lls-x.xbranch (for examplerhdh-1.9-lls-0.4.3).- Where
lls-x.xdenotes the Llama Stack version compatible with the configuration files.
- Where
- each shipped release is tagged on GitHub as
v<version>.
Sometimes during a release cycle the underlying Llama Stack version will change. To ensure that these changes are properly versioned, a release candidate should be cut.
- Create or update the release candidate branch for the outgoing release candidate snapshot (e.g.
rc-rhdh-1.9-lls-0.4.3). - Create a Git tag for the release candidate snapshot (e.g.
rc-v1.9.0). - Mark the release as pre-release to indicate it is not an official release.
When cutting a new release from the current main:
- Ensure
mainis stable and release-ready. - Create or update the release branch for the outgoing release snapshot (for example
rhdh-1.9-lls-0.4.3). - Create a Git tag for the outgoing release snapshot (for example
v1.9.0). - Update
mainto the next active release (configs, images, docs, and compose wiring). - Update
README.mdrelease metadata onmain:Llama Stack VersionbadgeRHDH Releasebadge- version table row
- Keep
README.mdrelease metadata updated inrhdh-x.xbranches as well when that branch receives a fix release.
Critical fixes for older releases are made in their release branch:
- Branch from
rhdh-x.x-lls-x.x. - Apply and validate the fix.
- Merge back into
rhdh-x.x-lls-x.x. - Update
README.mdrelease metadata in that release branch (including theRHDH Releasebadge) if any release values changed. - Tag the patched release (for example
v1.9.1for a patch release line). - Cherry-pick the fix to
mainif it still applies to the current release.