+26
-0
lines changedFilter options
+26
-0
lines changed Original file line number Diff line number Diff line change
@@ -5,6 +5,7 @@
5 5
* [Forking SRT on GitHub](#forking-srt-on-github)
6 6
* [Building SRT](#building-srt)
7 7
* [Project Structure](#project-structure)
8 +
* [Versioning](#versioning)
8 9
* [Coding Rules](#coding-rules)
9 10
* [Submitting an Issue](#submitting-an-issue)
10 11
* [Submitting a Pull Request](#submitting-a-pull-request)
@@ -121,6 +122,31 @@ The SRT installation has the following folders:
121 122
* *test - unit tests for the library.
122 123
* *testing - the folder contains applications used during development: `srt-test-live`, `srt-test-file`, etc. Use `-DENABLE_TESTING=ON` to include in the build.
123 124 125 +
## Versioning
126 + 127 +
The SRT library is versioned as `major.minor.patch`, e.g. v1.4.3.
128 +
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).
129 + 130 +
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.
131 + 132 +
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.
133 +
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.
134 + 135 +
By default the SRT library `SO`/`DYLIB` name is suffixed with `major.minor` version (starting from SRT v1.4.3):
136 +
- `libsrt.so.1.4`-> `libsrt.so.1.4.3`.
137 +
- `libsrt.so.1.4`-> `libsrt.so.1.4.4`
138 +
- `libsrt.so.1.5`-> `libsrt.so.1.5.0`
139 +
- ...
140 + 141 +
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.
142 + 143 +
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:
144 +
- `libsrt.so.1`-> `libsrt.so.1.4.2`.
145 +
- `libsrt.so.1`-> `libsrt.so.1.3.4`
146 +
- `libsrt.so.1`-> `libsrt.so.1.3.0`
147 +
- ...
148 + 149 + 124 150
## Coding Rules
125 151 126 152
TBD.
You can’t perform that action at this time.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4