Lines Matching +full:half +full:- +full:phase
6 The Zephyr project releases on a time-based cycle, rather than a feature-driven
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
19 - Release tagging procedure:
21 - linear mode on main branch,
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
25 stabilization phase. During the stabilization phase, only stabilization
29 - Development phase: all changes are considered and merged, subject to
31 - Stabilisation phase: the release manager creates a vN-rc1 tag and the tree
32 enters the stabilization phase
33 - CI sees the tag, builds and runs tests; Test teams analyse the report from the
35 - The release owner, with test teams and any other needed input, determines if the
37 - If it is a go for a release, the release owner lays a tag release vN at the
43 :figclass: align-center
51 `Official GitHub Wiki <https://github.com/zephyrproject-rtos/zephyr/wiki/Release-Management>`_.
54 Development Phase
64 The development phase lasts for approximately three months. At the end of this time,
65 the release owner will declare that the development phase is over and releases the first
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
72 Stabilization Phase
81 rule, if you miss submitting your code during the development phase for a given
84 they do not touch any other in-tree code, they cannot cause regressions and
88 The mainline release owner releases new -rc drops once or twice a week; a normal
89 series will get up to somewhere between -rc4 and -rc6 before the code base is
105 - The release criteria documents all the requirements of our target audience for
107 - The target audiences for each release can be different, and may overlap
108 - The criteria at any given time are not set in stone: there may be requirements
114 - No blocker bugs / blocking issues
115 - All relevant tests shall pass on ``Tier 0`` platforms
116 - All relevant tests shall pass on Tier 0 and 1 platforms (at least 1 per
118 - All applicable samples/tests shall build on Tiers 0, 1 and 2
119 - All high and critical static analysis and security issues addressed
120 - Release Notes are up-to-date.
139 - Only mark bugs as blockers if the software (Zephyr) must not be released with
141 - All collaborators can add or remove blocking labels.
142 - Evaluate bugs as potential blockers based on their severity and prevalence.
143 - Provide detailed rationale whenever adding or removing a blocking label.
144 - Ensure all blockers have the milestone tagged.
145 - Release managers have final say on blocking status; contact them with any questions.
154 .. list-table:: Release Milestones
156 :header-rows: 1
158 * - Timeline
159 - Checkpoint
160 - Description
161 - Owner
162 * - T-5M
163 - Planning
164 …- Finalize dates for release, Assign release owner and agree on project wide goals for this releas…
165 - TSC
166 * - T-7W
167 - Review target milestones
168 - Finalize target milestones for features in flight.
169 - Release Engineering
170 * - T-4W
171 - Release Announcement
172 - Release owner announces feature freeze and timeline for release.
173 - Release Manager
174 * - T-3W
175 - Feature Freeze (RC1)
176 - No new features after RC1, ONLY stabilization and cosmetic changes, bug and doc
178 - Release Engineering
179 * - T-2W
180 - 2nd Release Candidate
181 …- No new features after RC2, ONLY stabilization and cosmetic changes, bug and doc fixes are allowe…
182 - Release Manager
183 * - T-1W
184 - Hard Freeze (RC3)
185 - Only blocker bug fixes after RC3, documentation and changes to release notes are allowed.
188 - Release Manager
189 * - T-0W
190 - Release
191 -
192 - Release Manager
200 - Release [Major].[Minor].[Patch Level]
201 - Release Candidate [Major].[Minor].[Patch Level]-rc[RC Number]
202 - Tagging:
204 - v[Major].[Minor].[Patch Level]-rc[RC Number]
205 - v[Major].[Minor].[Patch Level]
206 - v[Major].[Minor].99 - A tag applied to main branch to signify that work on
210 work-in-progress main branch version. Presence of this tag allows generation of
218 :figclass: align-center
228 Long-term support releases are designed to be supported and maintained
234 - **Product focused**
235 - **Extended Stabilisation period**: Allow for more testing and bug fixing
236 - **Stable APIs**
237 - **Quality Driven Process**
238 - **Long Term**: Maintained for an extended period of time (at least 2.5 years)
239 overlapping previous LTS release for at least half a year.
258 stabilization period. Feature freeze of regular releases happens 3-4 weeks
260 by 3 weeks with the feature freeze occurring 6-7 weeks before the anticipated
266 Zephyr LTS provides a stable and long-lived foundation for developing
271 mature and well-established implementations with stable APIs that are
274 - API Freeze (LTS - 2)
276 - All stable APIs need to be frozen 2 releases before an LTS. APIs can be extended
280 - Device Drivers (i2c.h, spi.h)...
281 - Kernel (k_*):
282 - OS services (logging,debugging, ..)
283 - DTS: API and bindings stability
284 - Kconfig
286 - New APIs for experimental features can be added at any time as long as they
288 - Feature Freeze (LTS - 1)
289 - No new features or overhaul/restructuring of code covering major LTS features.
291 - Kernel + Base OS
292 - Additional advertised LTS features
294 - Auxiliary features on top of and/or extending the base OS and advertised LTS features
305 - Compliance with published coding guidelines, style guides and naming
307 - Static analysis reports
309 - Regular static analysis on the complete tree using available commercial and
310 open-source tools, and documentation of deviations and false positives.
312 - Documented components and APIS
313 - Requirements Catalog
314 - Verification Plans
315 - Verification Reports
316 - Coverage Reports
317 - Requirements Traceability Matrix (RTM)
318 - SPDX License Reports
328 released. Support and maintenance for an LTS release stops at least half a year
334 :figclass: align-center
371 - Tests are both built and run in these platforms in CI, and therefore runtime
373 - Supported by the Zephyr project itself, commitment to fix bugs in releases.
374 - One Tier 0 platform is required for each new architecture.
375 - Bugs reported against platforms of this tier are to be evaluated and treated as
381 - Commitment from a specific team to run tests using twister device
383 on a regular basis using open-source and publicly available drivers.
384 - Commitment to fix bugs in time for releases. Not supported by "Zephyr Project"
386 - General availability for purchase
387 - Bugs reported against platforms of this tier are to be evaluated and treated
393 - Platform implementation is available in upstream, no commitment to testing,
395 - Has a dedicated maintainer who commits to respond to issues / review patches.
396 - Bugs reported against platforms of this tier are NOT considered as
402 - Platform implementation is available, but no owner or unresponsive owner.
403 - No commitment to support is available.
404 - May be removed from upstream if no one works to bring it up to tier 2 or better.
405 - Bugs reported against platforms of this tier are NOT considered as
432 generates 'lightweight' tags regardless of release or pre-release). You should
435 key you can opt to remove the ``-s`` option from the commands below.
443 This section uses tagging 1.11.0-rc1 as an example, replace with
454 ``release: Zephyr 1.11.0-rc1`` as the commit subject. Merge
460 $ git tag -s -m "Zephyr 1.11.0-rc1" v1.11.0-rc1
466 $ git show v1.11.0-rc1
470 $ git push git@github.com:zephyrproject-rtos/zephyr.git v1.11.0-rc1
498 $ git tag -s -m "Zephyr 1.11.0" v1.11.0
508 $ git push git@github.com:zephyrproject-rtos/zephyr.git v1.11.0
513 * Copy the overview of ``docs/releases/release-notes-1.11.rst``