Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[docs] Added note on versioning #2311

Merged
merged 3 commits into from May 3, 2022
Merged

[docs] Added note on versioning #2311

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5f6b0f5
[docs] Added note on versioning
maxsharabayko Apr 25, 2022
719dce7
Fixed typos
maxsharabayko Apr 25, 2022
cb56745
Update developers-guide.md
maxsharabayko Apr 28, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
26 changes: 26 additions & 0 deletions docs/dev/developers-guide.md
View file
Open in desktop
Expand Up @@ -5,6 +5,7 @@
* [Forking SRT on GitHub](#forking-srt-on-github)
* [Building SRT](#building-srt)
* [Project Structure](#project-structure)
* [Versioning](#versioning)
* [Coding Rules](#coding-rules)
* [Submitting an Issue](#submitting-an-issue)
* [Submitting a Pull Request](#submitting-a-pull-request)
Expand Down Expand Up @@ -121,6 +122,31 @@ The SRT installation has the following folders:
* *test - unit tests for the library.
* *testing - the folder contains applications used during development: `srt-test-live`, `srt-test-file`, etc. Use `-DENABLE_TESTING=ON` to include in the build.

## Versioning

The SRT library is versioned as `major.minor.patch`, e.g. v1.4.3.
Due to legacy reasons SRT library version also defines SRT protocol version, announced in the dedicated field of the handshake packet (see the Handshake section of the [SRT Internet Draft](https://datatracker.ietf.org/doc/html/draft-sharabayko-srt-01#section-3.2.1).

The patch version upgrade usually means improvements and/or bug fixes, that do not affect SRT [API/ABI compatibility](https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C++) and do not significantly change the library behavior. Thus, an application can relatively safely update onto the next SRT patch release.

Any minor version upgrade means SRT might be no longer **fully** compliant with the OLD API/ABI and/or old behavior or contains notable changes in the source code.
A certain amount of care should be taken considering the upgrade to the new minor release. A proper testing should be done, and the review of changes listed in the release notes.

By default the SRT library `SO`/`DYLIB` name is suffixed with `major.minor` version (starting from SRT v1.4.3):
- `libsrt.so.1.4`-> `libsrt.so.1.4.3`.
- `libsrt.so.1.4`-> `libsrt.so.1.4.4`
- `libsrt.so.1.5`-> `libsrt.so.1.5.0`
- ...

This way upgrading the app with dynamic SRT linking to the latest patch release is quite easy, while upgrading to the new minor release must happen with awareness and thus might require rebuilding certain modules of the solution.

All SRT versions prior to SRT v1.4.3 had a single `SO`/`DYLIB` name `libsrt.so.1`, while ABI incompatibility could be broken. Thus it was not safe to perform wide deployment of different SRT library versions with the same ABI version:
- `libsrt.so.1`-> `libsrt.so.1.4.2`.
- `libsrt.so.1`-> `libsrt.so.1.3.4`
- `libsrt.so.1`-> `libsrt.so.1.3.0`
- ...


## Coding Rules

TBD.
Expand Down