| /Zephyr-Core-3.6.0/doc/project/ |
| D | release_process.rst | 3 Release Process
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
14 maintain the quality of the overall release without delays because of one or two
17 The Zephyr release model was loosely based on the Linux kernel model:
19 - Release tagging procedure:
22 - release branches for maintenance after release tagging.
23 - Each release period will consist of a development phase followed by a
24 stabilization phase. Release candidates will be tagged during the
31 - Stabilisation phase: the release manager creates a vN-rc1 tag and the tree
[all …]
|
| D | proposals.rst | 11 block a release. This is an incremental enhancement to a feature that already
16 that is not part of any release plans yet, that has not been vetted, and needs
38 willingness to drive implementation of the feature in an upcoming release, and
63 Roadmap and Release Plans
66 Project roadmaps and release plans are both important tools for the project, but
68 communicates the high-level overview of a project's strategy, while a release
72 - The project roadmap communicates the why; a release plan details the what
73 - A release plan spans only a few months; a product roadmap might cover a year
93 Release Plans
96 The release plan comes into play when the project roadmap's high-level strategy
[all …]
|
| D | project_roles.rst | 91 * Responsibility to participate in the quality verification and release
140 Release Engineering Team member, Release Manager, but are no longer engaged
159 by the other Maintainers, the Release Engineering team can set an assignee when
176 The Static Analysis Audit team works closely with the release engineering
177 team to ensure that static analysis defects opened during a release
195 Release Engineering Team
200 * The members of the Release Engineering team are expected to fill
201 the Release Manager role based on a defined cadence and selection process.
202 * The cadence and selection process are defined by the Release Engineering
206 Release Engineering team has the following rights and responsibilities:
[all …]
|
| /Zephyr-Core-3.6.0/.github/workflows/ |
| D | release.yml | 1 name: Create a Release
10 release:
35 - name: Create empty release notes body
37 echo "TODO: add release overview and notes link" > release-notes.txt
39 - name: Create Release
41 uses: actions/create-release@v1
47 body_path: release-notes.txt
51 - name: Upload Release Assets
52 id: upload-release-asset
53 uses: actions/upload-release-asset@v1
|
| /Zephyr-Core-3.6.0/doc/releases/ |
| D | eol_releases.rst | 4 Release notes for end-of-life releases of Zephyr RTOS are kept here for historical purposes.
11 release-notes-1.?
12 release-notes-1.*
13 release-notes-2.[0-6]
14 release-notes-3.[0-4]
|
| D | index.rst | 12 :ref:`west` to :ref:`get_the_code` of the release you are interested in.
15 https://docs.zephyrproject.org/ (use the version selector to select your release
18 Release Life Cycle and Maintenance
33 A Zephyr :ref:`Long Term Support (LTS) <release_process_lts>` release is
37 Support and maintenance for an LTS release stops at least half a year
38 after the following LTS release is published.
46 - Currently supported Long Term Support (LTS) release.
57 | Release | Release date | EOL |
68 Release Notes
71 Release notes contain a list of changes that have been made to the different
[all …]
|
| D | release-notes-1.5.rst | 6 The Zephyr Engineering team is glad to announce the release of Zephyr Kernel
7 1.5.0. This is the first release to follow the 3-month release cadence.
8 This release includes numerous fixes and support for major features.
11 Major enhancements included with the release:
213 * ``ZEP-461`` - Release 1.4.0 has broken the BMI160 sample as well as an application based on it
269 - No workaround, will fix in future release.
275 - No workaround, will fix in future release.
278 - No workaround, will fix in future release.
281 - No workaround, will fix in future release.
284 - No workaround, will fix in future release.
[all …]
|
| /Zephyr-Core-3.6.0/.github/ |
| D | SECURITY.md | 8 - The most recent release, and the release prior to that.
11 At this time, with the latest release of v3.5, the supported
15 - v3.4: Prior release
16 - v3.5: Current release
|
| /Zephyr-Core-3.6.0/dts/bindings/input/ |
| D | zephyr,input-longpress.yaml | 30 # release before one second
31 input event: dev=buttons SYN type= 1 code= 11 value=0 # INPUT_KEY_0 release
33 input event: dev=longpress SYN type= 1 code= 30 value=0 # INPUT_KEY_A release
39 # wait for release
40 input event: dev=buttons SYN type= 1 code= 11 value=0 # INPUT_KEY_0 release
41 input event: dev=longpress SYN type= 1 code= 45 value=0 # INPUT_KEY_X release
|
| /Zephyr-Core-3.6.0/samples/boards/stm32/power_mgmt/blinky/src/ |
| D | main.c | 30 /* Release resource to release device clock */ in main()
35 /* Release resource to release device clock */ in main()
|
| /Zephyr-Core-3.6.0/tests/subsys/portability/cmsis_rtos_v2/src/ |
| D | semaphore.c | 24 /* Try taking semaphore after a TIMEOUT, but before release */ in thread_sema()
35 * and release it. in thread_sema()
41 "Semaphore release failure"); in thread_sema()
101 /* Release invalid semaphore */ in ZTEST()
103 "Semaphore release worked unexpectedly"); in ZTEST()
105 /* Release the semaphore to be used by the other thread */ in ZTEST()
107 zassert_true(status == osOK, "Semaphore release failure"); in ZTEST()
|
| D | mutex.c | 72 /* Try to release mutex without obtaining it */ in ZTEST()
93 zassert_true(status == osOK, "Mutex release failure"); in ZTEST()
95 /* Release mutex again as it was acquired twice */ in ZTEST()
97 zassert_true(status == osOK, "Mutex release failure"); in ZTEST()
99 /* Try to release mutex that was already released */ in ZTEST()
137 * and release it. in tThread_entry_lock_timeout()
175 /* Release the mutex to be used by the other thread */ in ZTEST()
|
| /Zephyr-Core-3.6.0/tests/subsys/portability/cmsis_rtos_v1/src/ |
| D | mutex.c | 62 /* Try to release mutex without obtaining it */ in ZTEST()
74 zassert_true(status == osOK, "Mutex release failure"); in ZTEST()
76 /* Release mutex again as it was acquired twice */ in ZTEST()
78 zassert_true(status == osOK, "Mutex release failure"); in ZTEST()
80 /* Try to release mutex that was already released */ in ZTEST()
105 * Trying to release it here should fail. in tThread_entry_lock_timeout()
116 * and release it. in tThread_entry_lock_timeout()
143 /* Release the mutex to be used by the other thread */ in ZTEST()
|
| D | semaphore.c | 24 /* Try taking semaphore after a TIMEOUT, but before release */ in thread_sema()
35 * and release it. in thread_sema()
41 "Semaphore release failure"); in thread_sema()
68 /* Release the semaphore to be used by the other thread */ in ZTEST()
70 zassert_true(status == osOK, "Semaphore release failure"); in ZTEST()
|
| /Zephyr-Core-3.6.0/doc/security/ |
| D | reporting.rst | 91 - The Zephyr release owners for the relevant releases affected by
131 Each Zephyr release shall contain a report of CVEs that were fixed in
132 that release. Because of the sensitive nature of these
133 vulnerabilities, the release shall merely include a list of CVEs that
178 - The current Long Term Stable (LTS) release.
183 backports, and apply them to any of the above listed release branches,
185 this release was made). All recommendations for
189 release manager that the backport pull request and issue are addressing
205 - The current release manager, and the release manager for historical
213 - As needed, release managers and maintainers may be invited to attend
|
| /Zephyr-Core-3.6.0/samples/posix/uname/src/ |
| D | main.c | 19 printf("release[%zu]: %s\n", sizeof(info.release), info.release); in main()
|
| /Zephyr-Core-3.6.0/include/zephyr/ |
| D | kernel_version.h | 26 * x -- major release
27 * y -- minor release
28 * z -- patchlevel release
|
| /Zephyr-Core-3.6.0/soc/arm/st_stm32/stm32wb/ |
| D | power.c | 46 /* Release ENTRY_STOP_MODE semaphore */ in lpm_hsem_lock()
82 /* Release RCC semaphore */ in pm_state_set()
88 /* Release RCC semaphore */ in pm_state_set()
105 /* Release ENTRY_STOP_MODE semaphore */ in pm_state_exit_post_ops()
130 /* Release RCC semaphore */ in pm_state_exit_post_ops()
|
| /Zephyr-Core-3.6.0/doc/connectivity/bluetooth/api/shell/ |
| D | csip.rst | 13 or a laptop. The client is able to lock and release members of a coordinated
37 all the members has been connected to, it can lock and release the set.
51 release_set :Release set
53 release :Release specific member [member_index]
123 Release set members:
151 release :Release the set [force]
|
| /Zephyr-Core-3.6.0/tests/drivers/clock_control/onoff/src/ |
| D | test_clock_control_onoff.c | 74 /* Attempt to release while ongoing start. Cannot do that */ in ZTEST()
92 /* Test checks if premature clock release works ok. If clock is released before
93 * it is started it is the best to do that release from the callback to avoid
94 * waiting until clock is started in the release context.
|
| /Zephyr-Core-3.6.0/doc/develop/api/ |
| D | api_lifecycle.rst | 165 - An entry in the "API Changes" section of the release notes for the next
166 upcoming release
167 - The labels ``API``, ``Breaking API Change`` and ``Release Notes``, as well as
189 section of the release notes.
195 For example, if an API was first deprecated in release 1.14,
207 - Include the deprecation in the "API Changes" of the release notes for the
208 next upcoming release
213 add it to the roadmap targeting the appropriate release
238 the release notes, mailing lists, Github issues and pull-requests.
242 release.
|
| /Zephyr-Core-3.6.0/tests/bluetooth/controller/ctrl_phy_update/src/ |
| D | main.c | 151 /* Make sure we use a correct type or the release won't work */ in ZTEST()
177 /* Release Tx */ in ZTEST()
189 /* Release RX node to now allow pre-alloc for DLE NTF */ in ZTEST()
212 /* Release Tx */ in ZTEST()
243 /* Release Ntf */ in ZTEST()
247 /* Release Ntf */ in ZTEST()
300 /* Release Tx */ in ZTEST()
357 /* Release Tx */ in ZTEST()
370 /* Release Ntf */ in ZTEST()
399 /* Make sure we use a correct type or the release won't work */ in ZTEST()
[all …]
|
| /Zephyr-Core-3.6.0/subsys/bluetooth/controller/ll_sw/ |
| D | ull_df_internal.h | 10 /* Release link to node_rx_iq_report memory. */
12 /* Release memory of node_rx_iq_report. */
|
| /Zephyr-Core-3.6.0/dts/bindings/mtd/ |
| D | jedec,spi-nor-common.yaml | 35 implies that the RDPD (0xAB) Release from Deep Power Down command
48 (1) tDPDD (Delay Time for Release from Deep Power-Down Mode)
49 (2) tCDRP (CSn Toggling Time before Release from Deep Power-Down Mode)
50 (3) tRDP (Recovery Time for Release from Deep Power-Down Mode)
|
| /Zephyr-Core-3.6.0/tests/bluetooth/controller/ctrl_collision/src/ |
| D | main.c | 210 /* Release Tx */ in ZTEST()
230 /* Release Tx */ in ZTEST()
278 /* Release Tx */ in ZTEST()
311 /* Release Ntf */ in ZTEST()
380 /* Release Tx */ in ZTEST()
425 /* Release Tx */ in ZTEST()
432 /* Release Ntf */ in ZTEST()
452 /* Release Tx */ in ZTEST()
483 /* Release Ntf */ in ZTEST()
538 /* Release Tx */ in ZTEST()
[all …]
|
