Release Process

The EdgeX Release process is outlined and maintained in the following documents:

• ADR-0007-Release-Automation
• ADR-0010-Release-Artifacts

Any references to the release process outside of these two documents may be useful in explaining the process but it shouldn't be construed as the point of record.

Release Process

1. Branching
   1. Normal releases are created off of the main branch. No branches are typically created for a normal release.
   2. If a bug fix or patch needs to be created to address an existing release a branch will be created off the tag of the released software version. 
   3. During code freeze, only bug and security fixes can now make it into the main branch unless truly exceptional. Typically a conversation between WG Chairs, Product Manager and Release Czar is encouraged for awareness.
2. Official Release
   1. An official release is a coordination between the Technical Steering Committee (TSC) members, Product Manager, and Release Czar.
   2. A release schedule is proposed several months before the release date. It will include a time for code freeze (typically 2 weeks) and a target date for the release to occur.
   3. During Code Freeze the QA/Test working group as well as the Security Working group focus on testing and ensuring the release content is ready.
   4. During or at the end of Code Freeze the TSC members will vote to release or not.
   5. The Release Czar will merge a release manifest .yaml file into the CD-Management repository to build/stage/tag and release the desired artifacts. This PR typically gets approved by the product manager and relevant TSC members.
   6. After the release is complete, an announcement will be made by the TSC that the main branch is open for new contributions and PRs can be merged into main again.

Example Release Checklist

• A release checklist was created during the Kamakura release to help identify the sequencing of steps needed to perform a release with example commits.