Last year Zephyr branched 2.7 LTS from main. Our company has settled on the LTS for production use, but would still like the updates/fixes which comes from it, e.g. 5 days ago 2.7.2 was released.
It does though seem that some people (me included) would like to test the new release 3.0.0 (github issue).
I propose splitting Zephyr into the current zephyr framework and a new zephyr_lts framework, allowing the current LTS to be updated alongside the newest version.
Trying to figure out how this works I found that in the st-stm32 repo, the only change when updating Zephyr is a single line. Can this really be true? Does it somehow hook into the Zephyr tags or how does this work?
I will be helping in making this addition, should someone help me overcome this small hurdle.
You always can switch between framework versions using platform = ststm32 @ x.y.z SemVer specification. See pio pkg install — PlatformIO latest documentation
I am aware that I can change the platform, currently it is locked at ststm32@15.0.0 for Zephyr 2.7.0.
But what happens when the next platform e.g. 16.0.0 includes Zephyr 3.0.0, and none contains 2.7.2. Then there is no way for me to get to 2.7.2, or even 2.7.3 when that comes. I am sure you will not create a 16.0.1 with Zephyr 2.7.3 as that would introduce breaking changes to people not assigning a platform version.
Another approach would be to only include the LTS and let people tinker with newer versions manually with lib_deps (which seems a bit complicated for exactly Zephyr).
2.7.2 will be a part of the v15.x branch. We increment a major version only if there are breaking changes.
This is the reason why we recommend using platform = ststm32 @ ^15 instead of platform = ststm32.
You need:
Ah, so I can expect the future 2.7.x versions to be released under ststm32 v15.x, and 3.0.0 on ststm32 v16.x or higher?
Exactly!
P.S: What could we improve in PlatformIO?
