[BUG] Cannot properly set SRT version patch above 10

[jeandube]

In CMakeList.txt set (SRT_VERSION 1.4.11) generates version 0x0001040b while 0x00010411 is desired.

The version string SRT_VERSION_STRING define is OK ("1.4.0"), so is the lib name "libsrt.so.1.4.10" but the numerical value SRT_VERSION_VALUE used in srt handshake and in application code to enable SRT features not present in all versions does not work as expected

#if (SRT_VERSION_VALUE >= 0x00010490) //1.4.91: pre-released 1.5.0 w/OutPaceMode
#define SRT_HAS_STRICTENC 1
#define SRT_HAS_ENFORCEDENCRYPTION 1
#define SRT_HAS_STREAMID 1
#define SRT_HAS_LISTENCALLBACK 1
#define SRT_HAS_GETVERSION 1
#define SRT_HAS_GROUP 1
#define SRT_HAS_OUTPACEMODE 1

#elif (SRT_VERSION_VALUE >= 0x00010400) //1.4.0
<<snip>>

When not using an official release of SRT in product and to "highlight" this difference in products I would like to "color" the SRT version: for example 1.4.21 would be a modified 1.4.2. Also using hex letters would be nice too but the path is not considered an hex number ex: set(SRT_VERSION 1.4.1a) or set(SRT_VERSION 1.4.a1).

For example when a close-to-be-released version is not yet released, it still report the previous release 1.4.1 for soon-to-be-released 1.5.0. I could then use 1.4.91 or 1.4.f1.

[maxsharabayko]

The function that constructs the version integer (used in the handshake) is the following:

inline ATR_CONSTEXPR uint32_t SrtVersion(int major, int minor, int patch)
{
    return patch + minor*0x100 + major*0x10000;
}

SrtVersion(1, 4, 11) = 0x01040b

0x00010411 would be confusing.

A similar function is defined in version.h.in.

#define SRT_MAKE_VERSION(major, minor, patch) \
   ((patch) + ((minor)*0x100) + ((major)*0x10000))

I agree we need a way to distinguish release version 1.4.1 from the further development prev v1.5.0 versions.
Not sure if 1.4.91 or 1.4.f1 is a good numbering though.

Some ideas.

• Use `0xF*`` for development versions? E.g. v1.4.1 (0x010401) and v1.4.241 (0x0104F1) for development version (almost as suggested by @jeandube). Can/should this version be shared in the handshake?

• Use odd patch version as development, e.g. 1.4.0 - release, 1.4.1 - development, then 1.4.2 - release. It will be not very good for the end-user to understand why we always skip odd versions.

• Change SRT version right after the release. E.g. v1.4.0 goes out. Change SRT version to 1.4.1 right after the release. Cons: still release and development versions are not distinguished.

• Maybe we could use the remaining part of the uint32 integer? patch + minor*0x100 + major*0x10000 + 1 * 0x1000000 for development version? Compatibility should be considered then. This integer can't be sent in the handshake, as the version will be greater than any existing one.

• Create a separate definition for the development version? #define SRT_DEV_VER 1. Not sure how to use it though.

[jeandube]

A combined idea, odd versions with letters: 1.4.0 release, 1.4.1a, 1.4.1b,...1.4.1f (various development levels to be defined), 1.4.2 release, release never have a letter (easier o remember than odd or even). While introducing features we can require a MINVERSION with letter and leave this requirement in released code since the increasing version order is respected. Or not for experimental features that can come and go.

[jeandube]

Something wrong in the previous comment, 1.4.2<1.4.1a<1.4.1f, unless we trick the version comparison rules.

[ethouris]

Would that mean that the particular number for the version is only allowed 0-9, or that it's a requirement only for the very minor number and the remaining combinations are reused for the in-development stage?

Just the coding-decoding rules would get a little bit more complicated.

Just if we theoretically reach the 1.9.5 version, then the new major release will still be 1.10.0 encoded as 0x00010a00. I don't think it should be a problem as long as we have some high level translation facility and the hex number is not to be used directly (or only if you know how the high level translation rules work).

[jeandube]

Maybe the formula has problem beyond the last digit: 10 * 0x100 shall be computed as 0x10 * 0x100 so 1.10.5 is 0x00011000. So the 32-bit hex "shows" the version. I only saw the problem on the last digit but exists on all. If we agree on the correspondence between the string and binary versions the development/release version scheme can be discussed in a separate issue.