include: video: rollback video api version to 0.8.0

[avolmat-st]

The video API is currently set to v1.1.0 after having been promoted to version v1.0.0 (leading to making the API stable) after its introduction in Zephyr version 2.1.

The API is still going though extensive changes, such as ControlFramework, video buffer pool handling, RTIO based buffer managements updates in order to allow making it fit with intended use-cases.

Considering its current adoption situation in Zephyr, platforms relying on it and tests, it should rather be considered as Unstable instead of Stable. As such, set the version to 0.8.0.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[avolmat-st]

This PR follows a point raised in PR #100628 (#100628 (comment)) in which video api is modified. As stated in the comment, it turns out that the video API is currently set to version v1.1.0, making it automatically a stable api.

The API is still under going rather big updates now and I think it shouldn't be considered as stable for the moment and challenge the fact that it was promoted to stable previously.

I understand that rollback of a version number is not really proper, please consider this as a temporary solution in order to raise this issue and figure out a way to discuss about this point.

[teburd]

If we've had a release with 1.x out already then it might be too late to go back.

Instead the right approach might be moving forward with a new 2.x type API that is unstable.

I'm not the video maintainer but I tend to agree this is a bit awkward. At the same time I completely empathize with the goal of rolling back the API version.

[henrikbrixandersen]

I would like to hear from the two video maintainers before moving on with this, but given that the video API has been in the tree since v2.1 in 2019, I don't think marking it stable in v3.7 in 2023 was premature.

[JarmouniA]

Not possible, since it has been released.
There is no such thing as rollback in the process documented in https://docs.zephyrproject.org/latest/develop/api/api_lifecycle.html

[avolmat-st]

Thank you all for your comments. Indeed as I wrote in my second comment, I also think that a rollback in the version is not appropriate.
The only reason why I mentioned this was, first to get some feedback and moreover, based on the api_lifecycle document, Stable means api version > v1.0.0, hence experimental or unstable means version has to be below < 1.0.0.

I would like to hear from the two video maintainers before moving on with this, but given that the video API has been in the tree since v2.1 in 2019, I don't think marking it stable in v3.7 in 2023 was premature.

Maybe it is not that important to focus on the date now but in my understanding, this has been marked as Stable in 2020, not 2023, but I might have misunderstood the commit.

@ngphibang, @josuah, could you comment about the point above ?
(@ngphibang made a comment on the related PR here: #100628 (comment))

[ngphibang]

@henrikbrixandersen @teburd @JarmouniA @carlescufi

The first Video API was merged in 2019, supporting a basic pipeline (mt9m114 → CSI) on a single platform: i.MX RT1064. Shortly after, a few additional sensor drivers were added (ov2640, ov7725). It was marked as Stable a few months later (#100628 (comment), if I understand correctly) and remained (nearly) unchanged for several years—until recent developments in the last 1–2 years (c.f. slide 4 https://static.sched.com/hosted_files/osseu2025/7d/Video4Zephyr_EOSS_2025_Final.pdf?_gl=1*1hn5ugx*_gcl_au*MTk3Mzc3ODk1Ni4xNzY2NTMwNTgx*FPAU*MTk3Mzc3ODk1Ni4xNzY2NTMwNTgx), including: devicetree representation, frame interval / selection target APIs, CCI (Camera Control Interface), UVC, pipeline management, control framework, m2m support, buffer management rework and transition to RTIO (ongoing). These changes aim to make the API more aligned with more real-world use cases. However, when implementing these updates, we overlooked the fact that the Video API had already been marked as Stable ...

Is it possible to make an exception and roll back the version status (to Unstable), or is there another approach that allows us to continue evolving the API easily ? There are still ongoing PRs (e.g., buffer management, control framework improvements), and at least support for basic/realistic scenarios such as multi-camera setups and ISP integration is still missing.