[libcamera-devel] versioning

[Laurent Pinchart]

Hi Javier,

On Wed, Aug 17, 2022 at 06:39:42PM +0200, Javier Martinez Canillas wrote:
> On 8/15/22 21:17, Christian Rauch via libcamera-devel wrote:
> > Am 15.08.22 um 13:59 schrieb Eric Curtin:
> >> On Mon, 15 Aug 2022 at 06:29, Laurent Pinchart via libcamera-devel wrote:
> >>> On Sun, Aug 14, 2022 at 11:44:05PM +0200, Christian Rauch via libcamera-devel wrote:
> >>>> Hi Laurent,
> >>>>
> >>>> I think the SONAME is not the primary reason for tagging/versioning.
> >>>> Having API versions is mainly used to check compatibility for other
> >>>> projects. That means that the version information has to be encoded in
> >>>> some project file, e.g. *.pc files. Using a SONAME is really just useful
> >>>> if you want to have multiple versions of a library installed or if you
> >>>> want to make sure that you only link a specific version.
> >>>
> >>> Bumping the SONAME is a requirement from distributions when a new
> >>> version breaks ABI compatibility, so I think this is very important. It
> >>> will also help avoiding users facing bugs due to incompatibilities
> >>> between the version an application was compiled against and the version
> >>> installed on the system.
> 
> Agreed.
> 
> >> This is very important. I also am not the biggest fan of automating
> >> the version number bumping against a git mechanism. I have worked on
> >> projects like this and although it is convenient it is not ideal for
> >> package maintainers amongst other use cases like building against a
> >> tarball, etc. Fedora/EPEL are one such example where you upload the
> >> sources, you are not connected to the real origin repo directly at
> >> all.
> 
> Also agreed with this. I wonder how much value it would add to bump this
> automatically, specially since the plan is to add proper ABI checking to
> only bump the major version when there is backward incompatible changes.
> 
> As Kieran said, libabigail is quite popular for this and there are other
> tools, some of these mentioned in this Fedora wiki page [0].
> 
> But I don't think these two should be coupled, for example it can be done
> manually this time knowing that some backward incompatible changes were
> made since it was versioned as 0.0.0 and the next time do it once the ABI
> checker determined that needs to be bumped again.
>  
> > The SONAME is important, but I still think that the versioning of the
> > source is even more important. Without checking for the right version,
> > you may encounter compilation failures. If you distribute the *.so files
> > with your project (e.g. in a snap, flatpak or other "container"), or
> > build everything from source, then the SONAME does not matter so much,
> > but you will still need a versioned source.
> >>
> >> So I would propose manual bumps when required and not tie specifically
> >> to the version control system.
> >
> > This is certainly also an option and I do not have a strong opinion on this.
> 
> That would be my option too as mentioned, but don't have a strong opinion
> either. I personally like how the libvirt project does. Since they have a
> stable API/ABI, they never changed the major version which is still after
> years set to 0.
> 
> One of the core developers has written an excellent good blog post [1] that
> explains how they do versioning, but it also provides context and describes
> the different meanings of a project version (software, package, SONAME, etc).
> 
> For Fedora, we don't have strict requirements of the SONAME versioning. As
> long as it follows some convention so we can give heads-up to other package
> maintainers when there is a SONAME bump. So that the package can be updated
> and built in tandem with the other packages that depend on a given package.
> 
> Until there are official libcamera tarball releases, we will continue using
> git snapshots in the SRPM (e.g: [2]) and follow the packaging guidelines in
> Fedora for this [3].
> 
> [0]: https://fedoraproject.org/wiki/How_to_check_for_ABI_changes_in_a_package
> [1]: https://www.berrange.com/posts/2011/01/13/versioning-in-the-libvirt-library/
> [2]: https://src.fedoraproject.org/rpms/libcamera/blob/f37/f/libcamera.spec#_6
> [3]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snapshots

Thanks for the pointers, that's useful information.

We will likely have a look at this in the not too distant future, but I
believe it will have to wait for after ELC-E, as spare time is
traditionally an even rarer resource in the conference preparation
period.

-- 
Regards,

Laurent Pinchart