On Mon, Jan 31, 2022 at 1:11 PM Quentin Monnet <quentin@xxxxxxxxxxxxx> wrote: > > Since the notion of versions was introduced for bpftool, it has been > following the version number of the kernel (using the version number > corresponding to the tree in which bpftool's sources are located). The > rationale was that bpftool's features are loosely tied to BPF features > in the kernel, and that we could defer versioning to the kernel > repository itself. > > But this versioning scheme is confusing today, because a bpftool binary > should be able to work with both older and newer kernels, even if some > of its recent features won't be available on older systems. Furthermore, > if bpftool is ported to other systems in the future, keeping a > Linux-based version number is not a good option. > > It would make more sense to align bpftool's number on libbpf, maybe. > When versioning was introduced in bpftool, libbpf was in its initial > phase at v0.0.1. Now it moves faster, with regular version bumps. But > there are two issues if we want to pick the same numbers. First, that > would mean going backward on the numbering, and will be a huge pain for > every script trying to determine which bpftool binary is the most > recent (not to mention some possible overlap of the numbers in a distant > future). Then, bpftool could get new features or bug fixes between two > versions libbpf, so maybe we should not completely tie its versions to > libbpf, either. > > Therefore, this commit introduces an independent versioning scheme for > bpftool. The new version is v6.0.0, with its major number incremented > over the current 5.16.* returned from the kernel's Makefile. The plan is > to update this new number from time to time when bpftool gets new > features or new bug fixes. These updates could possibly lead to new > releases being tagged on the recently created out-of-tree mirror, at > https://github.com/libbpf/bpftool. > > Version number is moved higher in the Makefile, to make it more visible. > > Suggested-by: Andrii Nakryiko <andrii@xxxxxxxxxx> > Signed-off-by: Quentin Monnet <quentin@xxxxxxxxxxxxx> > --- > tools/bpf/bpftool/Makefile | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile > index bd5a8cafac49..b7dbdea112d3 100644 > --- a/tools/bpf/bpftool/Makefile > +++ b/tools/bpf/bpftool/Makefile > @@ -1,6 +1,8 @@ > # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > include ../../scripts/Makefile.include > > +BPFTOOL_VERSION := 6.0.0 > + It's going to be a PITA to not forget to update this :( As discussed, I'm fine with this, but I also recalled the versioning approach that libbpf-sys library is using (see [0]). Maybe we could steal some of those ideas. As in, base bpftool version on libbpf (with major version + 6 as you do here), but also have "-1", "-2", etc suffixes for bpftool releases for when libbpf version didn't change. Don't know, just throwing out the idea for your consideration. [0] https://github.com/libbpf/libbpf-sys#versioning > ifeq ($(srctree),) > srctree := $(patsubst %/,%,$(dir $(CURDIR))) > srctree := $(patsubst %/,%,$(dir $(srctree))) > @@ -39,9 +41,6 @@ LIBBPF_BOOTSTRAP := $(LIBBPF_BOOTSTRAP_OUTPUT)libbpf.a > LIBBPF_INTERNAL_HDRS := $(addprefix $(LIBBPF_HDRS_DIR)/,hashmap.h nlattr.h) > LIBBPF_BOOTSTRAP_INTERNAL_HDRS := $(addprefix $(LIBBPF_BOOTSTRAP_HDRS_DIR)/,hashmap.h) > > -ifeq ($(BPFTOOL_VERSION),) > -BPFTOOL_VERSION := $(shell make -rR --no-print-directory -sC ../../.. kernelversion) > -endif > LIBBPF_VERSION := $(shell make -r --no-print-directory -sC $(BPF_DIR) libbpfversion) > > $(LIBBPF_OUTPUT) $(BOOTSTRAP_OUTPUT) $(LIBBPF_BOOTSTRAP_OUTPUT) $(LIBBPF_HDRS_DIR) $(LIBBPF_BOOTSTRAP_HDRS_DIR): > -- > 2.32.0 >
