...
Role definition
The Release Manager will be is a volunteer position, much like WG chairs, that will be is staffed by contributors from member companies. The responsibility of a Release Manager 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.
...
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 Manager 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 |