Lines Matching full:and
8 companies, and individuals from the community.
11 balance of the latest technologies and features and excellent overall quality. A
26 changes such as bug fixes and documentation will be merged unless granted 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
34 build and test run and give an ACK/NAK to the build
35 - The release owner, with test teams and any other needed input, determines if the
60 sufficiently stable (and which is accepted by the maintainers and the wide community) is
62 (and all of the major changes) will be merged during this time.
65 the release owner will declare that the development phase is over and releases the first
69 new features has passed, and that the time to stabilize the next release of the
75 Over the next weeks and depending on the release milestone, only stabilization,
76 cosmetic changes, tests, bug and doc fixes are allowed (See :ref:`table
79 On occasion, more significant changes and new features will be allowed, but such
80 occasions are rare and require a TSC approval and a justification. As a general
84 they do not touch any other in-tree code, they cannot cause regressions and
89 series will get up to somewhere between -rc4 and -rc6 before the code base is
90 considered to be sufficiently stable and the release criteria have been achieved
102 people can understand and in ways that help new people to understand the process
103 and participate in creating successful releases:
107 - The target audiences for each release can be different, and may overlap
109 that have been overlooked, or that are new, and in these cases, the criteria
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
125 Blocker bug process kicks in during the release process and is in effect after the
130 A fix for a bug that is granted ``blocker`` status can be merged to 'main' and included in
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
142 - Evaluate bugs as potential blockers based on their severity and prevalence.
164 …- Finalize dates for release, Assign release owner and agree on project wide goals for this releas…
172 - Release owner announces feature freeze and timeline for release.
176 - No new features after RC1, ONLY stabilization and cosmetic changes, bug and doc
181 …- No new features after RC2, ONLY stabilization and cosmetic changes, bug and doc fixes are allowe…
185 - Only blocker bug fixes after RC3, documentation and changes to release notes are allowed.
198 The following syntax should be used for releases and tags in Git:
212 automated builds and CI tools.
221 Zephyr Code and Releases
228 Long-term support releases are designed to be supported and maintained
229 for an extended period and is the recommended release for
230 products and the auditable branch used for certification.
235 - **Extended Stabilisation period**: Allow for more testing and bug fixing
246 support and maintenance which includes general stability and bug fixes,
249 An LTS includes both mature and new features. API and feature maturity is
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.
257 Zephyr LTS development cycle differs from regular releases and has an extended
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
269 went through the Zephyr API lifecycle and stabilized over at least 2 releases.
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
283 - DTS: API and bindings stability
287 are standalone and documented as experimental or unstable features/APIs.
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.
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
320 Each release is created with the above products to document the quality and the
323 Long Term Support and Maintenance
326 A Zephyr LTS release is published every 2 years and is branched and maintained
328 released. Support and maintenance for an LTS release stops at least half a year
339 Changes and fixes flow in both directions. However, changes from main branch to an
340 LTS branch will be limited to fixes that apply to both branches and for existing
350 features and will be limited in scope. The LTS, development tree, and the
358 The initial and subsequent certification targets will be decided by the Zephyr project
361 Processes to achieve selected certification will be determined by the Security and
362 Safety Working Groups and coordinated with the TSC.
371 - Tests are both built and run in these platforms in CI, and therefore runtime
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.
383 on a regular basis using open-source and publicly available drivers.
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.
399 Tier 3: Deprecated and unsupported Platforms
425 The final release and each release candidate shall be tagged using the following
430 Tagging needs to be done via explicit git commands and not via GitHub's release
457 #. Tag and push the version, using an annotated tag::
472 #. Send an email to the mailing lists (``announce`` and ``devel``)
482 When all final release criteria has been met and the final release notes
483 have been approved and merged into the repository, the final release version
484 will be set and repository tagged using the following procedure:
495 #. Tag and push the version, using two annotated tags::
510 #. Find the new ``v1.11.0`` tag at the top of the releases page and
514 into the release notes textbox and link to the full release notes
517 #. Send an email to the mailing lists (``announce`` and ``devel``) with a link