Zephyr 4.3 Release A Comprehensive Checklist For A Smooth Launch

The Zephyr Project is gearing up for its 4.3 release, and to ensure a smooth and successful launch, a comprehensive checklist is essential. This article provides a detailed walkthrough of the tasks and considerations necessary for the Zephyr 4.3 release, covering everything from documentation to dependency updates and post-release activities. Let's dive in and make sure we're all on the same page for this exciting release.

Immediate Actions

Documentation Drafts: The Foundation of a Successful Release

First and foremost, it's crucial to have the documentation in place. We need to ensure that the draft release notes (doc/releases/release-notes-4.3.rst) and migration guide (doc/releases/migration-guide-4.3.rst) are ready with a feature summary from the previous release. If these documents don't exist, creating them is the first step. These documents serve as the primary source of information for users upgrading to the new version, so clarity and completeness are paramount.

• Draft Release Notes: These notes should highlight the new features, improvements, and bug fixes included in the 4.3 release. They should be written in a way that's accessible to both new and experienced Zephyr users.
• Migration Guide: This guide is essential for users upgrading from previous versions of Zephyr. It should outline any breaking changes, deprecated features, and steps required to migrate existing projects to the new version.

Ensuring these documents are included in the table of contents (TOC) is equally important. This makes them easily discoverable for anyone seeking information about the release. Think of it as setting the stage for a seamless transition. A well-documented release reduces friction and helps users quickly adopt the latest features and improvements.

Maintaining the Team: Assigning Responsibilities

Next up, let's talk about team roles. The MAINTAINERS.yml file should be updated to ensure the "Release Notes" maintainers point to the current release owners. This ensures that the right people are responsible for keeping the release notes accurate and up-to-date. This is a key part of effective release management.

The current release managers should be assigned to this issue, and it should be linked from the release plan. This creates a clear line of responsibility and ensures that everyone knows who is in charge. Consider this step as building the backbone of our release process, making sure that each task has a dedicated owner.

Ongoing Tasks: Monitoring and Maintenance

Continuous Integration (CI) Checks: Keeping the Build Clean

From day one, it’s crucial to keep an eye on the CI weekly runs. Check the CI runs for build failures and report or fix them. A stable build environment is essential for a successful release, and identifying and addressing issues early prevents them from snowballing into larger problems down the line.

Release Plan: Keeping Things on Track

The release plan must be kept up to date. This plan serves as the roadmap for the entire release process, outlining key milestones, deadlines, and responsibilities. Regular updates ensure that everyone is aware of the current status and any potential roadblocks.

Release Management Page: The Central Hub

The release management page should have an up-to-date schedule for the release. This page acts as a central repository for all release-related information, including timelines, tasks, and contact details. Maintaining an accurate schedule keeps the team aligned and helps manage expectations.

One Month Before RC1: Final Preparations

West Project Maintainers: Time for Updates

One month before Release Candidate 1 (RC1), it’s time to ping the West project maintainers. Remind them of the RC1/freeze deadline and ask them to consider if their modules should be updated. These external dependencies are vital to the overall health of the project, and ensuring they're up-to-date is crucial for compatibility and stability.

Extracting maintainer names from the MAINTAINERS files and creating an issue is an efficient way to manage this communication. Think of this as conducting a health check on all the moving parts of the system.

TSC Meeting Heads-Up: Spreading the Word

Start giving heads-ups on the TSC (Technical Steering Committee) meeting about the incoming freeze. This ensures that all stakeholders are aware of the impending deadline and can plan accordingly. Communication is key to a smooth release, and keeping everyone in the loop prevents last-minute surprises.

Deprecated Features: Time to Say Goodbye

Check on the status for features to be deprecated as listed. This is an opportunity to clean up the codebase and remove features that are no longer needed or have been replaced by newer alternatives. A well-maintained codebase is easier to manage and less prone to errors.

Zephyr SDK: The Toolkit Check

Ensure that the latest Zephyr SDK contains all the changes necessary to support the new features included in, or planned for, this release. If not, ping the SDK maintainer to release a new SDK version. The SDK is the toolkit that developers use, and it must be ready and aligned with the latest changes in Zephyr.

• Check if any toolchain-related enhancements and bug fixes are required for any pull requests targeting this release. If any of these enhancements and bug fixes are not part of the latest Zephyr SDK, a new SDK version must be released.
• Check that the Picolibc SHA in the latest SDK matches the picolibc module revision in west.yml. If they do not match, a new SDK version must be released.

This step is crucial for ensuring that developers have all the necessary tools to work with the new release effectively. Think of it as making sure everyone has the right equipment for the job.

Two Weeks Before RC1: Final Warnings

Mailing List and Discord: Last Call

Two weeks before RC1, send a heads-up about the incoming freeze to the dev-mailing list and Discord General channel. This is the final call for any last-minute changes or considerations. Spreading the word through multiple channels ensures that no one misses the announcement.

Pre-RC1: Milestones and Vulnerabilities

Next Release Milestone: Planning Ahead

Create the next release (v4.4.0) milestone so that features that don't make it into the current release can be assigned a milestone. This is about planning for the future and ensuring that work doesn't get lost in the shuffle.

Security Audit: Protecting the Project

Verify that all security-critical external components and external dependencies are up to date. Security is paramount, and this step ensures that the project is protected from known vulnerabilities. Check known vulnerabilities, and fix exploitable vulnerabilities or verify them as un-exploitable, consulting with the Security Working Group as needed. Security is not an option; it's a necessity.

Release Blockers: Clearing the Path

Make sure there are no pending “Release Blocker” issues. These are critical issues that must be resolved before the release can proceed. Clearing these issues ensures that the release is stable and reliable.

Deprecation Tracking: Managing the Lifecycle

Create a “Deprecated APIs/options to be removed by x.y” issue for 4.4 (N+3), linking to it from & to the 4.3 one. Remember to set the deprecation_tracker label. This helps manage the lifecycle of features and provides a clear roadmap for users.

Release Notes and Migration Guide Updates

Update the Release Notes and Migration Guide, reminding maintainers to update the release notes, especially in the RC1, RC2, and RC3 emails. These documents are the go-to resources for users, and keeping them current is essential.

After RC3, Before Final Release: Polishing and Finalizing

Backport Label: Managing Fixes

Create a backport v4.3-branch label and use it for fixes that aren’t bad enough to go into RC3. This provides a mechanism for managing fixes that are important but not critical enough to delay the release.

Finalize Documentation: The Last Review

Finalize the Release Notes and Migration Guide, reviewing the overview summary and details sections in doc/releases/release-notes-4.3.rst. Ensure that these documents are accurate, complete, and easy to understand.

Versioning and EOL: Housekeeping Tasks

Add the new version in doc/conf.py, doc/releases/index.rst, and doc/releases/eol_releases.rst. Remove EOL versions in the same files. These are essential housekeeping tasks that keep the documentation consistent and up-to-date.

Licensing Check: Ensuring Compliance

Update doc/LICENSING.rst for new components that do not have a license, consulting with the licensing team as needed. Licensing compliance is a critical aspect of any software release.

Remaining Release Notes: The Final Touches

Address any remaining Release Notes items. This is the final sweep to ensure that everything is in order.

Version Update: The Official Stamp

Update the version in VERSION, ensuring that EXTRAVERSION is empty, not zero. This is the official stamp that marks the release.

Tagging and Publishing: Making it Official

Tag v4.3.0 and update and publish the draft GitHub release created by the CI. Tag v4.3.0 in example-application and create a GitHub release from the tag. These steps make the release official and available to the public.

Directly After Tagging Release: Post-Release Tasks

Patch Level and Branching: Setting Up for Maintenance

Update the patch level in VERSION to 99 and tag v4.3.99. Create a v4.3-branch branch for 4.3.x releases from the v4.3.0 tag. This sets the stage for ongoing maintenance and bug fixes.

Announcements: Spreading the News

Email the mailing lists and announce the opening of the merge window. Create a marketing blog post announcing the release and post an update in GitHub Discussions and Discord channels. Spreading the word is crucial for adoption and awareness.

After Release: Wrapping Up and Looking Ahead

Milestone Management: Closing the Chapter

Move all PRs/Issues in the v4.3.0 milestone to the next milestone and close the v4.3.0 milestone. This is about closing the chapter on this release and preparing for the next one.

Next Release Checklist: Preparing for the Future

Create a checklist issue for the next release and add a comment to this issue linking to the next release checklist issue. This ensures that the release process is continuous and well-managed.

Maintainers and Security Policy: Keeping Information Current

Update MAINTAINERS.yml to point at the next release owners and update the current and supported version information in the Security Policy. This ensures that information is current and accurate.

First-Time Release Managers: Claiming the Badge

If you’re a first-time release manager, contact the project team to claim your Release Manager badge. Recognition and appreciation are important for team morale and engagement.

Next Release Documentation: Starting Fresh

Create draft release notes and migration guides for the next release, ensuring that the documentation is always one step ahead. This proactive approach ensures that documentation is ready when needed.

Regression Analysis

Identifying Regressions: Spotting Issues

Check if the release introduces any regressions. Regressions are issues that were working in previous releases but are now broken. Identifying and addressing regressions is crucial for maintaining stability.

Conclusion

The Zephyr 4.3 release checklist is a comprehensive guide designed to ensure a smooth and successful launch. By following these steps, the Zephyr Project team can minimize risks, maintain stability, and deliver a high-quality release that meets the needs of its users. Let's work together to make Zephyr 4.3 the best release yet!