Lines Matching +full:time +full:- +full:of +full:- +full:flight
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
11 balance of the latest technologies and features and excellent overall quality. 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
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>`_.
58 of patches for each release. At the beginning of each development cycle, the
59 main branch is said to be open for development. At that time, code which is deemed to be
61 merged into the mainline tree. The bulk of changes for a new development cycle
62 (and all of the major changes) will be merged during this time.
64 The development phase lasts for approximately three months. At the end of this time,
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
84 they do not touch any other in-tree code, they cannot cause regressions and
85 should be safe to add at any time).
87 As fixes make their way into the mainline, the patch rate will slow over time.
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.
133 Bugs of moderate severity and higher that have impact on all users are typically
136 Contributors and member of the release engineering team shall follow these
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
208 start of v1.8 process. The tag corresponds to
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)
250 documented and tracked. The footprint and scope of mature and stable APIs expands
252 and new hardware while keeping a stable foundation that evolves over time.
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
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
267 products. To guarantee stability of the APIs and the implementation of such
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
271 mature and well-established implementations with stable APIs that are
272 supported during the lifetime of the release LTS.
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
295 can be added at any time and should be marked as experimental if applicable
300 The Zephyr project follows industry standards and processes with the goal of
302 following products to track progress, integrity and quality of the software
305 - Compliance with published coding guidelines, style guides and naming
306 conventions and documentation of deviations.
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
321 state of the software when it was released.
334 :figclass: align-center
349 An auditable code base is to be established from a defined subset of Zephyr OS
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
447 located in the root of the Git repository to match the version for
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
487 located in the root of the Git repository. Set ``EXTRAVERSION``
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
510 #. Find the new ``v1.11.0`` tag at the top of the releases page and
513 * Copy the overview of ``docs/releases/release-notes-1.11.rst``