| Message ID | 20260903-kbingham-abi-trailers-v1-0-72ae051c912a@ideasonboard.com |
|---|---|
| Headers | show |
| Series |
|
| Related | show |
Hi All, Any objections or comments on this series ? The next release is coming up soon, this one feels like an easy thing to merge if no one objects. It's just about adding/conveying more useful information for me to ... make releases :-) -- Kieran Quoting Kieran Bingham (2026-09-03 15:51:49) > Extend the documentation to report on two new trailers... > ABI: > API: > > These trailers are accepted in the commit message in the trailer > section, but they are not validated and support free text. This allows > the contributor to specify the text appropriate to describe the breakage > rather than restrict to something which would become less meaningful. > > The checkstyle tool is extended to support this, and a final patch which > is not for merge offers a potential example of it's usage by taking text > reported by the abi-compliance-checker tool. > > Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> > --- > Kieran Bingham (3): > utils: checkstyle: Allow free form ABI/API trailers > Documentation: contributing: Add ABI/API trailer guide > DNI: TESTONLY: libcamera: camera: Add an ABI break in SensorConfig > > Documentation/contributing.rst | 21 +++++++++++++++++++++ > include/libcamera/camera.h | 2 ++ > utils/checkstyle.py | 9 +++++++-- > 3 files changed, 30 insertions(+), 2 deletions(-) > --- > base-commit: 63f9b4e5d9a9ba2ee2ebe1bfcdc0af453863c988 > change-id: 20260903-kbingham-abi-trailers-e251b0a26388 > > Best regards, > -- > -- > Kieran >
Hi 2026. 10. 19. 13:42 keltezéssel, Kieran Bingham írta: > Hi All, > > Any objections or comments on this series ? > > The next release is coming up soon, this one feels like an easy thing to > merge if no one objects. It's just about adding/conveying more useful > information for me to ... make releases :-) My concern that I have forgotten to send so far is that do we need both? I think maybe a single one would be enough, sometimes it's not entirely clear if something is an abi or api break, and duplicating things like in the example patch does not seem too appealing to me. > > -- > Kieran > > Quoting Kieran Bingham (2026-09-03 15:51:49) >> Extend the documentation to report on two new trailers... >> ABI: >> API: >> >> These trailers are accepted in the commit message in the trailer >> section, but they are not validated and support free text. This allows >> the contributor to specify the text appropriate to describe the breakage >> rather than restrict to something which would become less meaningful. >> >> The checkstyle tool is extended to support this, and a final patch which >> is not for merge offers a potential example of it's usage by taking text >> reported by the abi-compliance-checker tool. >> >> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> >> --- >> Kieran Bingham (3): >> utils: checkstyle: Allow free form ABI/API trailers >> Documentation: contributing: Add ABI/API trailer guide >> DNI: TESTONLY: libcamera: camera: Add an ABI break in SensorConfig >> >> Documentation/contributing.rst | 21 +++++++++++++++++++++ >> include/libcamera/camera.h | 2 ++ >> utils/checkstyle.py | 9 +++++++-- >> 3 files changed, 30 insertions(+), 2 deletions(-) >> --- >> base-commit: 63f9b4e5d9a9ba2ee2ebe1bfcdc0af453863c988 >> change-id: 20260903-kbingham-abi-trailers-e251b0a26388 >> >> Best regards, >> -- >> -- >> Kieran >>
Quoting Barnabás Pőcze (2026-10-19 13:42:10) > Hi > > 2026. 10. 19. 13:42 keltezéssel, Kieran Bingham írta: > > Hi All, > > > > Any objections or comments on this series ? > > > > The next release is coming up soon, this one feels like an easy thing to > > merge if no one objects. It's just about adding/conveying more useful > > information for me to ... make releases :-) > > My concern that I have forgotten to send so far is that do we need both? > I think maybe a single one would be enough, sometimes it's not entirely > clear if something is an abi or api break, and duplicating things like > in the example patch does not seem too appealing to me. I'm not sure. Not every ABI break is an API break, and not every API break is an ABI break ... So to me - they're separate, but might be the same issue. Though if it was already specified as an ABI break, maybe that is a superset and wouldn't have to also be specified as an API change. Or it could be ABI_API: But this is ugly -- Kieran > > > > > > -- > > Kieran > > > > Quoting Kieran Bingham (2026-09-03 15:51:49) > >> Extend the documentation to report on two new trailers... > >> ABI: > >> API: > >> > >> These trailers are accepted in the commit message in the trailer > >> section, but they are not validated and support free text. This allows > >> the contributor to specify the text appropriate to describe the breakage > >> rather than restrict to something which would become less meaningful. > >> > >> The checkstyle tool is extended to support this, and a final patch which > >> is not for merge offers a potential example of it's usage by taking text > >> reported by the abi-compliance-checker tool. > >> > >> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> > >> --- > >> Kieran Bingham (3): > >> utils: checkstyle: Allow free form ABI/API trailers > >> Documentation: contributing: Add ABI/API trailer guide > >> DNI: TESTONLY: libcamera: camera: Add an ABI break in SensorConfig > >> > >> Documentation/contributing.rst | 21 +++++++++++++++++++++ > >> include/libcamera/camera.h | 2 ++ > >> utils/checkstyle.py | 9 +++++++-- > >> 3 files changed, 30 insertions(+), 2 deletions(-) > >> --- > >> base-commit: 63f9b4e5d9a9ba2ee2ebe1bfcdc0af453863c988 > >> change-id: 20260903-kbingham-abi-trailers-e251b0a26388 > >> > >> Best regards, > >> -- > >> -- > >> Kieran > >> >
2026. 10. 19. 15:40 keltezéssel, Kieran Bingham írta: > Quoting Barnabás Pőcze (2026-10-19 13:42:10) >> Hi >> >> 2026. 10. 19. 13:42 keltezéssel, Kieran Bingham írta: >>> Hi All, >>> >>> Any objections or comments on this series ? >>> >>> The next release is coming up soon, this one feels like an easy thing to >>> merge if no one objects. It's just about adding/conveying more useful >>> information for me to ... make releases :-) >> >> My concern that I have forgotten to send so far is that do we need both? >> I think maybe a single one would be enough, sometimes it's not entirely >> clear if something is an abi or api break, and duplicating things like >> in the example patch does not seem too appealing to me. > > I'm not sure. Not every ABI break is an API break, and not every API > break is an ABI break ... > > So to me - they're separate, but might be the same issue. Though if it > was already specified as an ABI break, maybe that is a superset and > wouldn't have to also be specified as an API change. As an (hopefully not too contrived) example, consider the following: struct thing { void *p; unsigned int x; + unsigned int y; }; My issue is that this is an ABI change but not everywhere. How should that be handled? > > Or it could be > > ABI_API: But this is ugly I was thinking of a more general "Compat" or "Backwards-Compat". I believe what you're after in the end is "does this change have an effect on any of the public interfaces of libcamera?", right? > > -- > Kieran > >> >> >>> >>> -- >>> Kieran >>> >>> Quoting Kieran Bingham (2026-09-03 15:51:49) >>>> Extend the documentation to report on two new trailers... >>>> ABI: >>>> API: >>>> >>>> These trailers are accepted in the commit message in the trailer >>>> section, but they are not validated and support free text. This allows >>>> the contributor to specify the text appropriate to describe the breakage >>>> rather than restrict to something which would become less meaningful. >>>> >>>> The checkstyle tool is extended to support this, and a final patch which >>>> is not for merge offers a potential example of it's usage by taking text >>>> reported by the abi-compliance-checker tool. >>>> >>>> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> >>>> --- >>>> Kieran Bingham (3): >>>> utils: checkstyle: Allow free form ABI/API trailers >>>> Documentation: contributing: Add ABI/API trailer guide >>>> DNI: TESTONLY: libcamera: camera: Add an ABI break in SensorConfig >>>> >>>> Documentation/contributing.rst | 21 +++++++++++++++++++++ >>>> include/libcamera/camera.h | 2 ++ >>>> utils/checkstyle.py | 9 +++++++-- >>>> 3 files changed, 30 insertions(+), 2 deletions(-) >>>> --- >>>> base-commit: 63f9b4e5d9a9ba2ee2ebe1bfcdc0af453863c988 >>>> change-id: 20260903-kbingham-abi-trailers-e251b0a26388 >>>> >>>> Best regards, >>>> -- >>>> -- >>>> Kieran >>>> >>
Quoting Barnabás Pőcze (2026-10-19 15:53:43) > 2026. 10. 19. 15:40 keltezéssel, Kieran Bingham írta: > > Quoting Barnabás Pőcze (2026-10-19 13:42:10) > >> Hi > >> > >> 2026. 10. 19. 13:42 keltezéssel, Kieran Bingham írta: > >>> Hi All, > >>> > >>> Any objections or comments on this series ? > >>> > >>> The next release is coming up soon, this one feels like an easy thing to > >>> merge if no one objects. It's just about adding/conveying more useful > >>> information for me to ... make releases :-) > >> > >> My concern that I have forgotten to send so far is that do we need both? > >> I think maybe a single one would be enough, sometimes it's not entirely > >> clear if something is an abi or api break, and duplicating things like > >> in the example patch does not seem too appealing to me. > > > > I'm not sure. Not every ABI break is an API break, and not every API > > break is an ABI break ... > > > > So to me - they're separate, but might be the same issue. Though if it > > was already specified as an ABI break, maybe that is a superset and > > wouldn't have to also be specified as an API change. > > As an (hopefully not too contrived) example, consider the following: > > struct thing { > void *p; > unsigned int x; > + unsigned int y; > }; > > My issue is that this is an ABI change but not everywhere. How should that be handled? That's why I recommended the output of abi-compliance-checker, as that's already easy to run from libcamera with just "./utils/abi-compat.sh" If it sees a break - then it's visible, and gave a reason. Rather than have people invent their own reasons, I would have thought just putting the reason from the tool is easy. > > > > > > Or it could be > > > > ABI_API: But this is ugly > > I was thinking of a more general "Compat" or "Backwards-Compat". > I believe what you're after in the end is "does this change have an > effect on any of the public interfaces of libcamera?", right? Yes, my key requirement is that I would like to record in the commit when something impacts the public API or ABI. I'm not fussed what form we use, I would just like to use something. -- Kieran > > > > > > -- > > Kieran > > > >> > >> > >>> > >>> -- > >>> Kieran > >>> > >>> Quoting Kieran Bingham (2026-09-03 15:51:49) > >>>> Extend the documentation to report on two new trailers... > >>>> ABI: > >>>> API: > >>>> > >>>> These trailers are accepted in the commit message in the trailer > >>>> section, but they are not validated and support free text. This allows > >>>> the contributor to specify the text appropriate to describe the breakage > >>>> rather than restrict to something which would become less meaningful. > >>>> > >>>> The checkstyle tool is extended to support this, and a final patch which > >>>> is not for merge offers a potential example of it's usage by taking text > >>>> reported by the abi-compliance-checker tool. > >>>> > >>>> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> > >>>> --- > >>>> Kieran Bingham (3): > >>>> utils: checkstyle: Allow free form ABI/API trailers > >>>> Documentation: contributing: Add ABI/API trailer guide > >>>> DNI: TESTONLY: libcamera: camera: Add an ABI break in SensorConfig > >>>> > >>>> Documentation/contributing.rst | 21 +++++++++++++++++++++ > >>>> include/libcamera/camera.h | 2 ++ > >>>> utils/checkstyle.py | 9 +++++++-- > >>>> 3 files changed, 30 insertions(+), 2 deletions(-) > >>>> --- > >>>> base-commit: 63f9b4e5d9a9ba2ee2ebe1bfcdc0af453863c988 > >>>> change-id: 20260903-kbingham-abi-trailers-e251b0a26388 > >>>> > >>>> Best regards, > >>>> -- > >>>> -- > >>>> Kieran > >>>> > >> >
Extend the documentation to report on two new trailers... ABI: API: These trailers are accepted in the commit message in the trailer section, but they are not validated and support free text. This allows the contributor to specify the text appropriate to describe the breakage rather than restrict to something which would become less meaningful. The checkstyle tool is extended to support this, and a final patch which is not for merge offers a potential example of it's usage by taking text reported by the abi-compliance-checker tool. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> --- Kieran Bingham (3): utils: checkstyle: Allow free form ABI/API trailers Documentation: contributing: Add ABI/API trailer guide DNI: TESTONLY: libcamera: camera: Add an ABI break in SensorConfig Documentation/contributing.rst | 21 +++++++++++++++++++++ include/libcamera/camera.h | 2 ++ utils/checkstyle.py | 9 +++++++-- 3 files changed, 30 insertions(+), 2 deletions(-) --- base-commit: 63f9b4e5d9a9ba2ee2ebe1bfcdc0af453863c988 change-id: 20260903-kbingham-abi-trailers-e251b0a26388 Best regards,