Page History

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

Template to set the workflow for any given release. The goal of the template here is to use well known and tested methods, simplify the process, and reduce any ambiguity that we can.  This helps to keep the focus on the product where it belongs by taking cognitive load out of managing releases.  This template should also not be seen as a final word; if someone has an objectively better method that improves this process then we should generally adopt that.

Some well known and tested methods we will adopt immediately

...

1. Snapshot repo: used for merged artifacts. After the committer has performed the code review (+2), has merged the code and the build is successful, the build artifact is within the Snapshot repo. It is expected to have multiple snapshots for a single repo per day. All artifacts have same version number.
2. Staging repo: used for Release candidate. Once a day, a new clean build is automatically performed. All artifacts have same version number. The Staging artifact is used for the release testing (Testing beyond unit tests).
3. Release repo: this is the place where the project team (or Linux Foundation Releng Team) stores the artifacts that are deemed stabled for being consumed by the other project teams. Each team decides when to release. It is not expected to get a new release every day. No TSC approval is required for getting a new release artifact.

...

General Development

1. All general work goes against the master branch in each project.
2. Individual Pull Requests will generate artifacts that are pushed to the Nexus snapshot repository.
3. Daily builds will build master and push an artifact into the staging repository, these should be considered release candidates.

Enumerate Services in Release

1. Simple list of all services that will be in the release.

Release Process

1. Branch Cutting
   1.   At some point before an official artifact release (at least 2 weeks).  A release branch will be created off of the master branch.
   2.  The master branch version will be rev'd to the desired version of a future release.
   3.  Only bug and security fixes can now make it into the release main branch unless truly exceptional.  Jenkins jobs will be instantiated for the release branchTypically a conversation between WG Chairs, Product Manager and Release Czar is encouraged for awareness.
2. Official Release
   1.  A leading representative from a particular project will initiate the release by doing the following:
      1. Submit a Project Service / Release Artifacts ticket via JIRA -  https://support.linuxfoundation.org/  - with the following information:
         1. Link to Jenkins staging job that produced artifact to be released
         2. Type of artifacts to be released (jar, go bin, container)
   2.  The EdgeX Release Engineer will release signed artifacts as requested and git tag the repository found at the sha checked out in the aforementioned Jenkins staging job.
   3.  RE will push the tag to https://github.com/edgexfoundry/$PROJECT_NAME
   4.  Project representation will PATCH bump the version of the project in the release branch in prep for next patch.

      2.  Generate or update named release manifest

             - This is the document which will enumerate each service and version that will be contained in a named release.

      3.  Individual service release

...

1. 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.