Lines Matching full:release

3 Release Process
10 A time-based release process enables the Zephyr project to provide users with a
12 roughly 4-month release cycle allows the project to coordinate development of
14 maintain the quality of the overall release without delays because of one or two
17 The Zephyr release model was loosely based on the Linux kernel model:
19 - Release tagging procedure:
22 - release branches for maintenance after release tagging.
23 - Each release period will consist of a development phase followed by a
24 stabilization phase. Release candidates will be tagged during the
31 - Stabilisation phase: the release manager creates a vN-rc1 tag and the tree
35 - The release owner, with test teams and any other needed input, determines if the
36 release candidate is a go for release
37 - If it is a go for a release, the release owner lays a tag release vN at the
42 :alt: Release Cycle
46 Release Cycle
51 `Official GitHub Wiki <https://github.com/zephyrproject-rtos/zephyr/wiki/Release-Management>`_.
58 of patches for each release. At the beginning of each development cycle, the
65 the release owner will declare that the development phase is over and releases the first
66 of the release candidates. For the codebase release which is destined to be
67 3.1.0, for example, the release which happens at the end of the development phase
68 will be called 3.1.0-rc1. The -rc1 release is the signal that the time to merge
69 new features has passed, and that the time to stabilize the next release of the
75 Over the next weeks and depending on the release milestone, only stabilization,
88 The mainline release owner releases new -rc drops once or twice a week; a normal
90 considered to be sufficiently stable and the release criteria have been achieved
91 at which point the final 3.1.0 release is made.
97 Release Criteria
101 for a release. This will help define when a release is "done" in terms that most
105 - The release criteria documents all the requirements of our target audience for
106 each Zephyr release
107 - The target audiences for each release can be different, and may overlap
112 Below is the high level criteria to be met for each release:
120 - Release Notes are up-to-date.
125 Blocker bug process kicks in during the release process and is in effect after the
127 release from happening. All blocker bugs shall be resolved before a release is
131 the release all the way until the final release date.
136 Contributors and member of the release engineering team shall follow these
137 guidelines for release blocker bugs:
145 - Release managers have final say on blocking status; contact them with any questions.
150 Release Milestones
154 .. list-table:: Release Milestones
164 …- Finalize dates for release, Assign release owner and agree on project wide goals for this releas…
169 - Release Engineering
171 - Release Announcement
172 - Release owner announces feature freeze and timeline for release.
173 - Release Manager
178 - Release Engineering
180 - 2nd Release Candidate
182 - Release Manager
185 - Only blocker bug fixes after RC3, documentation and changes to release notes are allowed.
186 Release notes need to be complete by this checkpoint. Release Criteria is
188 - Release Manager
190 - Release
192 - Release Manager
200 - Release [Major].[Minor].[Patch Level]
201 - Release Candidate [Major].[Minor].[Patch Level]-rc[RC Number]
229 for an extended period and is the recommended release for
232 An LTS release is defined as:
239 overlapping previous LTS release for at least half a year.
245 Zephyr LTS is the recommended release for product makers with an extended
259 before the scheduled release date. The stabilization period for LTS is extended
261 release date. The time between code freeze and release date is extended in this case.
268 APIs it is required that any release software that makes the core of the OS
270 This guarantees that we release many of the highlighted and core features with
272 supported during the lifetime of the release LTS.
320 Each release is created with the above products to document the quality and the
326 A Zephyr LTS release is published every 2 years and is branched and maintained
328 released. Support and maintenance for an LTS release stops at least half a year
329 after the following LTS release is published.
333 :alt: Long Term Support Release
337 Long Term Support Release
409 Release Procedure
412 This section documents the Release manager responsibilities so that it serves as
413 a knowledge repository for Release managers.
415 Release Checklist
418 Each release has a GitHub issue associated with it that contains the full
419 checklist. After a release is complete, a checklist for the next release is
425 The final release and each release candidate shall be tagged using the following
430 Tagging needs to be done via explicit git commands and not via GitHub's release
431 interface. The GitHub release interface does not generate annotated tags (it
432 generates 'lightweight' tags regardless of release or pre-release). You should
439 .. tab:: Release Candidate
444 the appropriate release candidate version.
448 this release candidate. The ``EXTRAVERSION`` variable is used to
454 ``release: Zephyr 1.11.0-rc1`` as the commit subject. Merge
473 with a link to the release
475 .. tab:: Final Release
480 appropriate final release version.
482 When all final release criteria has been met and the final release notes
483 have been approved and merged into the repository, the final release version
488 variable to an empty string to indicate final release::
493 ``release: Zephyr 1.11.0`` as the commit subject. Merge
511 edit the release with the ``Edit tag`` button with the following:
513 * Copy the overview of ``docs/releases/release-notes-1.11.rst``
514 into the release notes textbox and link to the full release notes
518 to the release