RFC: cmake: limit Zephyr SDK to 0.16.x series for Zephyr 3.7 LTS

[tejlmand]

Zephyr SDK compatibility level 0.16 is now an LTS intended for
Zephyr v3.7 LTS.

Thus, limit the upper Zephyr SDK lookup to <0.17, so that developers
working with Zephyr v3.7 LTS and latest Zephyr main can install both
Zephyr SDK 0.16.x along side Zephyr SDK >=0.17 and have the Zephyr SDK
0.16.x series being used for v3.7 LTS development.

---

This PR depends on a manual backport of #80194 which is included in this PR.
Fixes: #80200

[tejlmand]

@stephanosio @nashif @keith-packard based on zephyrproject-rtos/sdk-ng#809 (comment) I think it makes sense to place an upper limit on the Zephyr SDK, as we now consider the Zephyr SDK 0.16.x series an LTS.

Should we bring this to the TSC ?

[stephanosio]

based on zephyrproject-rtos/sdk-ng#809 (comment) I think it makes sense to place an upper limit on the Zephyr SDK, as we now consider the Zephyr SDK 0.16.x series an LTS.

Yes, thanks for implementing this.

Though, ultimately, we would want find_package(Zephyr-sdk a.b) to only look for the SDKs versions a.b.X as per the semantic versioning scheme discussed in zephyrproject-rtos/sdk-ng#608 -- this way, we do not have to make changes like this to previous Zephyr releases in the future.

Should we bring this to the TSC ?

Not sure if a TSC approval is needed for this change since this more or less is fixing a bug where an incompatible version of SDK is picked up by the Zephyr LTS release.

It would be good to mention it at a TSC meeting to raise more awareness, nevertheless.

[tejlmand]

Though, ultimately, we would want find_package(Zephyr-sdk a.b) to only look for the SDKs versions a.b.X as per the semantic versioning scheme discussed in zephyrproject-rtos/sdk-ng#608 -- this way, we do not have to make changes like this to previous Zephyr releases in the future.

but in such case the I believe we should have a Zephyr SDK v1.0.0 release, and actually start using the major version.
A bump from 0.16.x to 0.17.0 should generally not be considered a breaking change.

since this more or less is fixing a bug where an incompatible version of SDK is picked up by the Zephyr LTS release.

as long as we are using versions <1.0.0 then I think it's stretching it a bit to consider it a bug, but guess we're getting into semantics at this point 😉

It would be good to mention it at a TSC meeting to raise more awareness, nevertheless.

yep, I was not expecting any push-back on this, but awareness on those kind of changes are usually good.

[keith-packard]

I'm trusting that the cmake bits implement what it says on the tin...

[pdgendt]

Should this also get backported to 3.6 as it is still active?

[henrikbrixandersen]

Should this also get backported to 3.6 as it is still active?

Yes, I think it should.

[pdgendt]

Hmn marking backport only works for PRs that are merged to main.