Lines Matching +full:zephyr +full:- +full:main +full:- +full:ci +full:- +full:push +full:- +full:1
6 The Zephyr project releases on a time-based cycle, rather than a feature-driven
7 one. Zephyr releases represent an aggregation of the work of many contributors,
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
17 The Zephyr release model was loosely based on the Linux kernel model:
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>`_.
59 main branch is said to be open for development. At that time, code which is deemed to be
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
100 The main motivation is to clearly have the criteria in place that must be met
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
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.
130 A fix for a bug that is granted ``blocker`` status can be merged to 'main' and included in
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
207 v[Major].[Minor+1] has started. For example, v1.7.99 will be tagged at the
210 work-in-progress main branch version. Presence of this tag allows generation of
211 sensible output for "git describe" on main branch, as typically used for
212 automated builds and CI tools.
218 :figclass: align-center
221 Zephyr Code and Releases
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)
245 Zephyr LTS is the recommended release for product makers with an extended
257 Zephyr LTS development cycle differs from regular releases and has an extended
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
269 went through the Zephyr API lifecycle and stabilized over at least 2 releases.
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
300 The Zephyr project follows industry standards and processes with the goal of
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
326 A Zephyr LTS release is published every 2 years and is branched and maintained
327 independently from the main tree for at least 2.5 years after it was
334 :figclass: align-center
339 Changes and fixes flow in both directions. However, changes from main branch to an
349 An auditable code base is to be established from a defined subset of Zephyr OS
358 The initial and subsequent certification targets will be decided by the Zephyr project
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
376 a general bug in Zephyr and should be dealt with the highest priority.
378 Tier 1: Supported Platforms
381 - Commitment from a specific team to run tests using twister device
382 testing for the "Zephyr compatibility test suite" (details TBD)
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
388 as a general bug in Zephyr and should be dealt with medium to high priority.
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
397 a general bug in Zephyr.
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
406 a general bug in Zephyr.
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
455 the PR after successful CI.
457 #. Tag and push the version, using an annotated tag::
460 $ git tag -s -m "Zephyr 1.11.0-rc1" v1.11.0-rc1
466 $ git show v1.11.0-rc1
468 #. Push the tag::
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
494 the PR after successful CI.
495 #. Tag and push the version, using two annotated tags::
498 $ git tag -s -m "Zephyr 1.11.0" v1.11.0
506 #. Push the tag::
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``