Zephyr 3.4 Release Checklist

[stephanosio]

• Make sure the release plan is kept up to date:

  • See https://github.com/orgs/zephyrproject-rtos/projects/13

• Pre RC1 Steps

  • Create v3.4.1 and v3.5.0 milestone so that features that don't make it to the release can be assigned a milestone
  • Verify that all security-critical external components and external dependencies are up to date (previous: Zephyr 3.2 module updates overview #49678)
  • Check known vulnerabilities, and fix exploitable vulnerabilities or verify them as un-exploitable (ask Security working group).
  • Make sure there's no pending "Release Blocker" issues
  • 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 (@stephanosio) to release a new SDK version.
    • Check if any toolchain-related enhancements and bug fixes are required for any of the 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 version in the latest SDK matches the Picolibc module version in west.yml. If they do not match, a new SDK version must be released.

See https://docs.zephyrproject.org/latest/project/release_process.html#tagging for tagging details, release specific filters under https://github.com/zephyrproject-rtos/zephyr/wiki/Filters to find pending PRs.

---

• Release Notes WIP
  • Make sure to tell everybody to use the past tense (i.e. "X has been added" or "X is now Y")
  • Create draft doc/releases/release-notes-3.4.rst with feature summary from the previous one (if not there already)
  • Update doc/releases/release-notes-3.4.rst detailed sections (relative to 3.3.0 release) as important issues are addressed (subsystem owners). (previous: Zephyr 3.3 release notes overview #54495)

---

• Finalize Release Notes: (previous: Finalise release notes for v3.3.0 #54904)
  • Add list of addressed issues (spell check issue list and fix in GitHub as needed) using scripts/release/list_issues.py
  • Add list of known issues (spell check issue list and fix in GitHub as needed) by downloading the latest bug pickle and using scripts/dump_bugs_pickle.py
  • Review doc/releases/release-notes-3.4.rst overview summary and details sections
    • Request summary details from subsystem maintainers
• Update doc/develop/api/overview.rst (previous: doc: api: update overview page #50604)
• Update doc/conf.py (add version to relevant list in html_context)
• Update doc/LICENSING.rst for new components that do not have a license

---

• Remaining Release Notes (previous: Zephyr 3.3 release notes overview #54495)
• Check the CI bi-weekly run for build failures that should be fixed

---

• Update version in VERSION (EXTRAVERSION must be empty, not zero 0) (previous: release: Zephyr 3.3.0 #54950)
• Tag both v3.4.0 (see https://docs.zephyrproject.org/latest/project/release_process.html#tagging)
• Update and publish the draft GitHub release created by the CI.
• Tag v3.4.0 in example-application (previous: Zephyr 3.3.0 tagpoint example-application#31)

---

• After Release
  • Update patchlevel in VERSION (PATCHLEVEL = 99) (previous: VERSION: Bump to 3.3.99 #54956)
  • Create v3.4-branch branch for 3.4.x releases (from v3.4.0 tag, don't include the switch to patchlevel 99)
  • Create backport v3.4-branch label
  • Move all PRs/Issues in the v3.4.0 milestone to the next milestone
  • Close v3.4.0 milestone
  • Update current release and GitHub stats on the website (email Brett)
  • Email [email protected] & [email protected] lists about release and announce the opening of the merge window
  • Create checklist issue for next release
  • Add a comment to this issue linking to the next release checklist issue
  • Marketing Blog for announcing release (https://www.zephyrproject.org/blog)
  • Store the number of currently open PRs to keep track of post-release PR overhead over time
  • Update MAINTAINERS.yml "Release Notes" maintainers to point at the next release owners
  • Update current and supported version information in the Security Policy.

Previous checklist: #50898

[nashif]

Retrospective:

• submitting issues for each PR or change in the stabilisation phase.
• Sometimes it is an overkill to ask for trivial changes
• Release blocker definition needs to be refined and clarified

[kartben]

please see #57966

[kartben]

Re: "Update doc/develop/api/overview.rst" I just opened #58487. Would also agree with @fabiobaltieri's comments in #50604 that this list might not be all that helpful in the end (is it even complete?), and we should probably consider implementing something along the lines of #50604 (comment)