Part 1
요약·해설
0.x experimental·unstable, 1.x stable, patch·minor·major 증가 규칙과 공식 API maturity 표 664행을 보존합니다.
초기
0.1 · 0.8
안정
1.0 · Semantic Version
표
API · Version · Since
Part 2
접을 수 있는 영어 원문 전체
영어 원문 전체 펼치기
원문 SHA-256
33F1EB52217AC79032409C0EAB5B9360C6931AE3D454CA249BB0DCDA00EF581E
.. _api_overview:
API Overview
############
The table lists Zephyr's APIs and information about them, including their
current :ref:`stability level <api_lifecycle>`. More details about API changes
between major releases are available in the :ref:`zephyr_release_notes`.
The version column uses `semantic version <https://semver.org/>`_, and has the
following expectations:
* Major version zero (0.y.z) is for initial development. Anything MAY
change at any time. The public API SHOULD NOT be considered stable.
* If minor version is up to one (0.1.z), API is considered
:ref:`experimental <api_lifecycle_experimental>`.
* If minor version is larger than one (0.y.z | y > 1), API is considered
:ref:`unstable <api_lifecycle_unstable>`.
* Version 1.0.0 defines the public API. The way in which the version number
is incremented after this release is dependent on this public API and how it
changes.
* APIs with major versions equal or larger than one (x.y.z | x >= 1 ) are
considered :ref:`stable <api_lifecycle_stable>`.
* All existing stable APIs in Zephyr will be start with version 1.0.0.
* Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards
compatible bug fixes are introduced. A bug fix is defined as an internal
change that fixes incorrect behavior.
* Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards
compatible functionality is introduced to the public API. It MUST be
incremented if any public API functionality is marked as deprecated. It MAY
be incremented if substantial new functionality or improvements are
introduced within the private code. It MAY include patch level changes.
Patch version MUST be reset to 0 when minor version is incremented.
* Major version X (x.Y.z | x > 0) MUST be incremented if a compatibility
breaking change was made to the API.
.. note::
Version for existing APIs are initially set based on the current state of the
APIs:
- 0.1.0 denotes an :ref:`experimental <api_lifecycle_experimental>` API
- 0.8.0 denote an :ref:`unstable <api_lifecycle_unstable>` API,
- and finally 1.0.0 indicates a :ref:`stable <api_lifecycle_stable>` APIs.
Changes to APIs in the future will require adapting the version following the
guidelines above.
.. api-overview-table::
Part 3
한국어 전문 번역
API overview
표에는 Zephyr API와 각 API의 현재 stability level을 포함한 정보가 나열됩니다. Major release 사이의 API 변경 detail은 Zephyr release note에서 확인할 수 있습니다.
Version column은 Semantic Versioning을 사용하며 다음 규칙을 따릅니다.
- Major version 0인
0.y.z는 초기 개발 단계입니다. 언제든 무엇이든 바뀔 수 있으며 public API를 stable로 간주하면 안 됩니다.- Minor version이 최대 1인
0.1.z이면 API를 experimental로 봅니다. - Minor version이 1보다 큰
0.y.z | y > 1이면 API를 unstable로 봅니다.
- Minor version이 최대 1인
1.0.0은 public API를 정의합니다. 이후 version number 증가 방식은 이 public API와 그 변경 내용에 따라 결정됩니다.- Major version이 1 이상인
x.y.z | x >= 1API는 stable로 봅니다. - Zephyr의 모든 기존 stable API는 version
1.0.0으로 시작합니다.
- Major version이 1 이상인
- Backward-compatible bug fix만 도입하면 patch version Z인
x.y.Z | x > 0를 반드시 증가시켜야 합니다. Bug fix는 잘못된 동작을 고치는 internal change로 정의합니다. - Public API에 새 backward-compatible functionality를 도입하면 minor version Y인
x.Y.z | x > 0를 반드시 증가시켜야 합니다. Public API functionality를 deprecated로 표시할 때도 반드시 올립니다. Private code 안에 substantial한 새 functionality나 개선을 도입할 때 올릴 수 있으며 patch-level change도 포함할 수 있습니다. Minor version을 올릴 때 patch version은 반드시 0으로 reset합니다. - API에 compatibility-breaking change를 만들면 major version X인
x.Y.z | x > 0를 반드시 증가시켜야 합니다.
Source
출처
영어 원문에는 문단, 문서 지시문, 표, 코드, 코드 심벌, 경로를 그대로 보존했습니다.