SDL Message Versions in production

[mikeburke106]

@Heath-FoMoCo @idamaster

I'm currently working on a better way to propagate SDL message version through the system so RPC messages can create proper JSON structures based on what version of SDL is connected.

I connected to each of the 3 TDKs we have at Livio and we're seeing the following information:

Sync 3 TDK:

"syncMsgVersion":{
    "majorVersion":3,
    "minorVersion":0
}

2.0 TDK:

"syncMsgVersion":{
    "majorVersion":2,
    "minorVersion":0
}

1.1 TDK:

"syncMsgVersion":{
    "majorVersion":1,
    "minorVersion":2
}

Are there any other "syncMsgVersion"s in production that I need to be concerned with?

[mikeburke106]

Also, in this same vein, I see that OnSystemRequest has 2 keys defined specifically for "V1" (url and timeout).

Are these only applicable to major version 1, or are they applicable to major version 2 as well?

[stefanek22]

The list of possible combinations currently are:

{
 [1,0], [1,1], [1,2],
 [2,0], [2,1]*,
 [3.0]*, [3,1]*,
 [4,0]*
}

* not released in production yet

[mikeburke106]

Thanks @stefanek22. What is the versioning process for these values? i.e. what has to change in the message protocol to warrant an increase in major vs. minor version number?

Did any RPC definitions change between any of these versions that I need to account for in the mobile libs?

[stefanek22]

Up to this point the versioning process has been mainly based on major feature set expansion (many features added in v2.x and a major mobile navi addition in v3.x). The minor revisions indicated some change / expansion in the feature set (e.g. v1.1 added TBT state and a Driver Distraction mode).

[mikeburke106]

How do we distinguish many features from some features?

Is the major version number enough information for RPCs to determine how to build their JSON messages? In other words, are RPC message definitions modified in minor version changes or is that reserved for major version changes?

[justinjdickow]

I wrote an issue against deprecating in the rpc specification - my point of view is that we should use deprecation on the RPC spec in the same way we do for public APIs in the mobile libraries to increase minor version, and backwards incompatible changes increase major version.