Skip to end of metadata
Go to start of metadata

Version 1 - 2018-12-06

Role definition

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.

Selection process

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

Timeline of responsibilities

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.



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

  • No labels