Lines Matching +full:merge +full:- +full:date
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
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
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>`_.
68 will be called 3.1.0-rc1. The -rc1 release is the signal that the time to merge
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.
131 the release all the way until the final release 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)
258 stabilization period. Feature freeze of regular releases happens 3-4 weeks
259 before the scheduled release date. The stabilization period for LTS is extended
260 by 3 weeks with the feature freeze occurring 6-7 weeks before the anticipated
261 release date. The time between code freeze and release date is extended in this case.
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
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
493 ``release: Zephyr 1.11.0`` as the commit subject. Merge
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``