Lines Matching +full:100 +full:base +full:- +full:t
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
70 code base has begun.
81 hardware; if they do not touch any other in-tree code, they cannot cause
85 The mainline release owner releases new -rc drops once or twice a week; a normal
86 series will get up to somewhere between -rc4 and -rc6 before the code base is
100 .. csv-table:: Bug Count Release Thresholds
110 for release 2.4.0, 100 for release 2.5.0, and 50 for release 2.6.0
118 .. list-table:: Release Milestones
119 :widths: 15 25 100 25
120 :header-rows: 1
122 * - Timeline
123 - Checkpoint
124 - Description
125 - Owner
126 * - T-5M
127 - Planning
128 …- Finalize dates for release, Assign release owner and agree on project wide goals for this releas…
129 - TSC
130 * - T-7W
131 - Review target milestones
132 - Finalize target milestones for features in flight.
133 - Release Engineering
134 * - T-4W
135 - Release Announcement
136 - Release owner announces feature freeze and timeline for release.
137 - Release Manager
138 * - T-3W
139 - Feature Freeze (RC1)
140 - No new features, ONLY stabilization and cosmetic changes, bug and doc fixes are allowed.
141 - Release Engineering
142 * - T-2W
143 - 2nd Release Candidate
144 - No new features, ONLY stabilization and cosmetic changes, bug and doc fixes are allowed.
145 - Release Manager
146 * - T-1W
147 - Hard Freeze (RC3)
148 - Only blocker bug fixes, documentation and changes to release notes are allowed.
151 - Release Manager
152 * - T-0W
153 - Release
154 -
155 - Release Manager
165 - Release [Major].[Minor].[Patch Level]
166 - Release Candidate [Major].[Minor].[Patch Level]-rc[RC Number]
167 - Tagging:
169 - v[Major].[Minor].[Patch Level]-rc[RC Number]
170 - v[Major].[Minor].[Patch Level]
171 - v[Major].[Minor].99 - A tag applied to main branch to signify that work on
175 work-in-progress main branch version. Presence of this tag allows generation of
183 :figclass: align-center
193 Long-term support releases are designed to be supported and maintained
199 - **Product focused**
200 - **Extended Stabilisation period**: Allow for more testing and bug fixing
201 - **Stable APIs**
202 - **Quality Driven Process**
203 - **Long Term**: Maintained for an extended period of time (at least 2.5 years)
223 stabilization period. Feature freeze of regular releases happens 3-4 weeks
225 by 3 weeks with the feature freeze occurring 6-7 weeks before the anticipated
231 Zephyr LTS provides a stable and long-lived foundation for developing
236 mature and well-established implementations with stable APIs that are
239 - API Freeze (LTS - 2)
241 - All stable APIs need to be frozen 2 releases before an LTS. APIs can be extended
245 - Device Drivers (i2c.h, spi.h)...
246 - Kernel (k_*):
247 - OS services (logging,debugging, ..)
248 - DTS: API and bindings stability
249 - Kconfig
251 - New APIs for experimental features can be added at any time as long as they
253 - Feature Freeze (LTS - 1)
254 - No new features or overhaul/restructuring of code covering major LTS features.
256 - Kernel + Base OS
257 - Additional advertised LTS features
259 - Auxiliary features on top of and/or extending the base OS and advertised LTS features
270 - Compliance with published coding guidelines, style guides and naming
272 - Regular static analysis on the complete tree using available commercial and
273 open-source tools and documentation of deviations and false positives.
274 - Documented components and APIS
275 - Requirements Catalog
276 - Verification Plans
277 - Verification Reports
278 - Coverage Reports
279 - Requirements Traceability Matrix (RTM)
280 - SPDX License Reports
296 :figclass: align-center
308 Auditable Code Base
311 An auditable code base is to be established from a defined subset of Zephyr OS
318 auditable code base.
350 generates 'lightweight' tags regardless of release or pre-release). You should
353 key you can opt to remove the ``-s`` option from the commands below.
361 This section uses tagging 1.11.0-rc1 as an example, replace with
372 ``release: Zephyr 1.11.0-rc1`` as the commit subject. Merge
377 $ git tag -s -m "Zephyr 1.11.0-rc1" v1.11.0-rc1
378 $ git push git@github.com:zephyrproject-rtos/zephyr.git v1.11.0-rc1
406 $ git tag -s -m "Zephyr 1.11.0" v1.11.0
407 $ git push git@github.com:zephyrproject-rtos/zephyr.git v1.11.0
412 * Copy the overview of ``docs/releases/release-notes-1.11.rst``