books/The-API-Book
1
0
Fork 0
mirror of https://github.com/twirl/The-API-Book.git synced 2025-05-31 22:09:37 +02:00
Code Issues Releases Activity

style fix

Browse Source
This commit is contained in:
Sergey Konstantinov 2023-03-03 11:50:20 +02:00 committed by GitHub
parent f17729e43b
commit 47a255c3bc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
src/en/clean-copy/01-Introduction/05.md
View File

@ -1,14 +1,14 @@
### On Versioning
Here and throughout we firmly stick to [semver](https://semver.org/) principles of versioning.
Here and throughout this book, we firmly stick to [semver](https://semver.org/) principles of versioning.
1. API versions are denoted with three numbers, i.e. `1.2.3`.
1. The first number (a major version) increases when backwards-incompatible changes in the API are introduced.
2. The second number (a minor version) increases when new functionality is added to the API, keeping backwards compatibility intact.
3. The third number (a patch) increases when a new API version contains bug fixes only.
2. The first number (a major version) increases when backwards-incompatible changes in the API are introduced.
3. The second number (a minor version) increases when new functionality is added to the API, keeping backwards compatibility intact.
4. The third number (a patch) increases when a new API version contains bug fixes only.
Sentences “major API version” and “new API version, containing backwards-incompatible changes” are therefore to be considered equivalent ones.
Sentences “a major API version” and “new API version, containing backwards-incompatible changes” are therefore to be considered equivalent ones.
It is usually (though not necessary) agreed that the last stable API version might be referenced by either a full version (e.g. `1.2.3`) or a reduced one (`1.2` or just `1`). Some systems support more sophisticated schemes of defining the desired version (for example, `^1.2.3` reads like “get the last stable API version that is backwards-compatible to the `1.2.3` version”) or additional shortcuts (for example, `1.2-beta` to refer to the last beta-version of the `1.2` API version family). In this book, we will mostly use designations like `v1` (`v2`, `v3`, etc.) to denote the latest stable release of the `1.x.x` version family of an API.
It is usually (though not necessary) agreed that the last stable API release might be referenced by either a full version (e.g. `1.2.3`) or a reduced one (`1.2` or just `1`). Some systems support more sophisticated schemes of defining the desired version (for example, `^1.2.3` reads like “get the last stable API release that is backwards-compatible to the `1.2.3` version”) or additional shortcuts (for example, `1.2-beta` to refer to the last beta release of the `1.2` API version family). In this book, we will mostly use designations like `v1` (`v2`, `v3`, etc.) to denote the latest stable release of the `1.x.x` version family of an API.
The practical meaning of this versioning system and the applicable policies will be discussed in more detail in the “Backwards Compatibility Problem Statement” chapter.