Version 1 - 2018-12-06
The Release Tsar is a volunteer position, much like WG chairs, that is staffed by contributors from member companies. The responsibility of a Release Tsar is to coordinate the common tasks of each release that span across working groups, ensuring that the required release tasks are being performed on schedule and escalating any potential problems to the TSC and relevant working groups as early as possible.
The Release Tsar will provide a brief update in the TSC weekly calls, detailing the time remaining until the freeze or release, the progress made on Github issues targeting that release, and any potential release blockers or features that will not make the freeze date that they may be aware of.
While participation in WG meetings is not required, the Release Tsar should attend any of those where there is a concern about the number of open issues, potential release blockers, or major features still waiting to land as a freeze date approaches.
If a major feature is not ready before the feature freeze date but is ready soon after, and if that feature would ideally be included in the release, the developers can ask the Release Tsar for a freeze exception. The Release Tsar will present the case for this exception (both the benefit of the feature and the potential impact on the rest of the release) to the TSC, who will decide to allow it or bump the feature to a future release.
The Release Tsar role will be shared by EdgeX Foundry member companies on a rotating basis. Each release will have its own Release Tsar who will be selected from the member company whose turn it is in the rotation. Any company who can contribute to this role should contact the TSC to request being added to the rotation.
The current list of companies volunteering to staff the Release Tsar role are:
IOTech
Intel
Dell
VMWare
The Release Tsar role has an 8 month term. This allows them to cover the full 6 months of the regular release cycle, as well as one month before the cycle starts to prepare for it and one month after to help the next Release Tsar get started.
Because the dates of each release will vary, the times here are given as time before (-) or after (+) a given release.
Date | Task |
T - 7 months | New Release Tsar is selected and introduces themselves to the project. |
T - 6.5 months | Request version bump on all EdgeX Foundry projects, verify that they have been merged. |
T - 6 months | TSC Face to Face meeting |
T - 6 months | Collect list of features & issues from each working group that they plan on completing for the release (should be available after the TSC face to face meeting) |
T - 6 months | Create new “Release Schedule” wiki page, fill in dates for freezes, branching and final release (should be known after the TC face to face) |
T - 5 months | Request new Github milestone for the release, assign targeted issues to it |
T - 5 weeks | Send email reminder about upcoming feature freeze on the master branch |
T - 4 weeks | Send email announcing master branch feature freeze, request freeze exceptions for any late-landing features |
T - 3 weeks | Send email reminder about upcoming code freeze on the master branch |
T - 2 weeks | Send email announcing master branch code freeze, request that the Linux Foundation release engineer create a release branch from master |
T - 1 week | Send email announcing the release branch availability, lift the freeze on the master branch |
T - 1 week | Verify that developers/devops have configured CI to build staging artifacts (docker images, snaps) from the new release branch. |
T - 3 days | Generate Release Notes document (using release metrics script and providing highlights from the release) and publish it to the wiki. |
T - 2 days | Provide release information to marketing and LF PR for release announcement |
T - 1 day | Coordinate with WG chairs to identify which staging artifacts will be the official release, email the LF Release Engineer requesting that the release be made by providing them the Jenkins job for the desired artifact. |
T = 0 | Verify that stable release images have been published to Docker Hub |
T = 0 | Verify that stable snap package has been published to the Snap store |
T = 0 | Verify that the release announcement has gone out with link to Release Notes |
T + 1 week | Send email announcing x.1 target release date and targeted features/bug fixes |
T + 2 weeks | Send email reminder about upcoming point release freeze |
T + 3 weeks | Send email announcing release branch code freeze |
T + 4 weeks | Verify that stable release artifacts (docker images, snaps) of the point release have been published |