[libcamera-devel] [PATCH 1/4] meson: Shared Object version handling

[Javier Martinez Canillas]

Hello folks,

I'll try to take a detailed look at the patches next week and give
feedback, but I see that there are some distro related questions,
so thought that would be better to answer those ASAP.

On 10/1/22 02:07, Laurent Pinchart wrote:
> On Sat, Oct 01, 2022 at 12:44:01AM +0100, Kieran Bingham wrote:
>> Quoting Laurent Pinchart (2022-10-01 00:29:06)
>>> On Fri, Sep 30, 2022 at 11:03:27PM +0100, Kieran Bingham wrote:
>>>> Quoting Laurent Pinchart (2022-09-30 21:50:44)

[...]

>>>>>>
>>>>>>>> +# We can continue to consider that a patch level increment should be
>>>>>>>> +# compatible.
>>>>>>>> +project_version = meson.project_version().split('.')
>>>>>>>> +soversion = project_version[0] + '.' + project_version[1]
>>>>>
>>>>> As we have libcamera_version and not just version, I'd have named the
>>>>> variable libcamera_soversion.
>>>>>
>>>>> Why do you use two components of the version only ? As we don't
>>>>> guarantee ABI stability, could we use all three components for now ?
>>>>> This could then be shortened to major.minor when we'll add ABI change
>>>>> detection (but still without ABI stability), and finally to just major
>>>>> once ABI stability will be guaranteed. Javier, do you have any opinion ?
>>>>
>>>> I believe we don't define ABI stability in either of major or minor. But
>>>> we 'do' (or can) in .patch. (We're also unlikely to create a .patch
>>>> relase, unless we find a specific need to fix something for a
>>>> distributions release, but distributions might still make patch
>>>> releases...).
>>>
>>> Why wouldn't we start with patch releases ?
>>
>> Becaause that prohibits anyone else adding fixes to that release point.
>>
>> If Ubuntu take libcamera-0.5 ... but there's a bug .. they can fix it
>> (or we can) in libcamera-0.5.1.
>>
>> If we do patch release that's not possible.
> 
> This is an area where Javier may shed some light. I see lots of
> libraries that make use of major, minor and patch themselves, it doesn't
> seem like the patch number is meant to be reserved for distributions.
> 
> At some point in the future I'm quite sure we'll have multiple
> maintained stable branches, with bug fix releases. We're not there yet,
> so I'd rather start by doing 0.0.x releases to start with, and see where
> it leads.
> 

I agree with Laurent here. Upstream projects can make use of all the three
MAJOR.MINOR.PATCH version numbers, distros add their own release numbering
on top of it. For example, let's say we have a libcamera-0.5.1 release; a
distro would release that for example as libcamera-0.5.1-1.fc36.x86_64.

If later there's a bug (either in the packaging or in libcamera itself),
the distro can propose a fix for upstream, carry it as a downstream patch
in the meantime and release a new package as libcamera-0.5.1-2.fc36.x86_64.

It would be very rare for distro downstream patch either change the library
API/ABI or add a new a new feature in a backward compatible change, to need
a SONAME bump. So that's in complete control of upstream and distros should
not have a say there. They just need to pay attention to SONAME bumps since
is how upstream notifies downstream distros whether the new release breaks
backward compatibility or not.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat