When providing a new SDP version, provide for at least 1 release the previous version

[limdor]

Feature Request / Modification Description

#61 provided a new SDP version but it also removed the previous SDP version. It would be good if whenever a new SDP is release, the previous version could be provided for at least 1 release. This would allow project to do upgrades in a more incremental way.

How it looks like for projects right now:

• A bazel_cpp_toolchains version N is released that contains SDP version M
• Projects make start using bazel_cpp_toolchains version N with SDP version M
• A bazel_cpp_toolchains version N+1 is released that contains SDP version M+1 but not version M
• Projects update to bazel_cpp_toolchains version N+1 and SDP version M+1 at the same time in a single PR

How it would look like if this feature would be provided:

• A bazel_cpp_toolchains version N is released that contains SDP version M
• Projects make start using bazel_cpp_toolchains version N with SDP version M
• A bazel_cpp_toolchains version N+1 is released that contains SDP version M and version M+1
• Projects update to bazel_cpp_toolchains version N+1 and keep SDP at version M
• Projects update to SDP version M+1
• A bazel_cpp_toolchains version N+2 is released that contains SDP version M+1 but not version M

This is a pattern that is followed in several Bazel rules from https://registry.bazel.build/ and it would be good if this repository could also support it.

Expected Changes ot work products

• Requirements
• Architecture
• Safety Analysis
• Security Analysis
• Detailed Design
• Implementation and Testing
• all

Impact analysis

I do not see this as safety relevant. The only opened question that maintainers would have to answer is if in the version that multiple SDP versions are supported, if all can be used for production or the previous one is only provided by migration purposes. I would vote for allowing both version for production because I do not see a big overhead on enabling that, but if that would require a considerable amount of work, I could understand if only one version is officially supported. Still having both available would help for migration.

Safety or Security relevance

• none
• Safety relevant
• Security relevant

Expected required ASIL classification

QM

Expected Implementation Version (Release)

1.0

[nradakovic]

Hi Xavi,
We discussed some of these points on slack channel. I asked if someone needs the old version and if yes for how long. Also, the decision of infrastructure community was to not provide older version. Reason: the update of the version included minor changes without any impact on the interface between 8.0.3 and 8.0.4, in other words there were no incompatible changes in terms of API.
Regarding proposal, I will pass this down the chain and if community agrees on it, I have no problem implementing it.
One point to highlight here. The version matrix was never attended to hold multiple version of same package and most likely once we have stable SDP delivered from QNX, we will remove all current workarounds (also when it comes to selecting the platform constraints). If consumer needs dedicated (specific) version of SDP, he needs to set it up via provided extension.

[AlexanderLanin]

@limdor can you provide more concrete benefits please? Why would an incremental change be better than a single-PR merge?

Doesnt sound wrong in general, but something more concrete would be nice. As I assume this is additional effort.

[limdor]

When things go wrong, it is harder to figure out if the problem comes from the rule changes or from the OS upgrade.

[nradakovic]

The impact of SDP can easily be verified. That's why we have different versions of module. The idea is that backward compatibility in terms of relationship between configuration and SDP itself is always preserved. We didn't remove or update any existing tool reference from SDP, so verification of newer SDP package is also possible with older versions of toolchain module.
If we want to have more explicit release notes, I would say this should come from QNX. And again, we didn't do update without notifications. On project official channel, the info was added about adding new QNX SDP version.

[limdor]

Hi Xavi, We discussed some of these points on slack channel. I asked if someone needs the old version and if yes for how long. Also, the decision of infrastructure community was to not provide older version. Reason: the update of the version included minor changes without any impact on the interface between 8.0.3 and 8.0.4, in other words there were no incompatible changes in terms of API. Regarding proposal, I will pass this down the chain and if community agrees on it, I have no problem implementing it. One point to highlight here. The version matrix was never attended to hold multiple version of same package and most likely once we have stable SDP delivered from QNX, we will remove all current workarounds (also when it comes to selecting the platform constraints). If consumer needs dedicated (specific) version of SDP, he needs to set it up via provided extension.

Sorry I was not aware of this discussion. If no one requested that it make sense to not add it unnecessary. I was just not sure if this would be a general pattern or it would depend from version to version. I will just close it.