Re: [RFC] tools lib traceevent: How to do library versioning being in the Linux kernel source?

[Steven Rostedt]

[ Added the BPF folks ]

On Thu, 2 Jan 2020 15:42:52 -0300
Arnaldo Carvalho de Melo <arnaldo.melo@xxxxxxxxx> wrote:

> Em Thu, Jan 02, 2020 at 12:20:04PM -0500, Steven Rostedt escreveu:
> > This is a problem with living in the Linux source tree as tags and
> > branches in Linus's tree are for only the Linux kernel source itself.
> > This may work fine for perf, as it's not a library and there's not  
> 

> 
> libperf adopted the versioning and packaging practices introduced by
> tools/lib/bpf, perhaps you could do the same for tools/lib/traceevent
> and then we would have a standard for these cases?

I don't see libperf in my Debian testing installation, but I did find
libbpf.

> 
> The problem of having libperf, libbpf in distros is already being
> tackled for quite a while, would be interesting to follow what has
> happened in that area as well, Jiri knows more about this, Jiri?

Looking at the libbpf Makefile, it is getting the version from the
libbpf.map file.

What's the standard way for distributions to know when to use the
number? Only from Linux stable trees? That way, we can make fixes to the
library, but still need to remember to update the version number before
the release.

How does libbpf handle the version numbers with bug fixes? Does it get
updated one a kernel release if there are changes?

Obviously, we need to update the major number if the API changes in
anyway that is not compatible for a new application, which includes
adding new functions. Right?

-- Steve