Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp815746pxu; Wed, 14 Oct 2020 14:46:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwOXgzNK+RsqdhKM+xC0044cIE0MxWSJwQ+3Y8CQS028frq3TWLxRgGBAl1KRqLRBwceTM3 X-Received: by 2002:a05:6402:2208:: with SMTP id cq8mr1035174edb.191.1602711982209; Wed, 14 Oct 2020 14:46:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602711982; cv=none; d=google.com; s=arc-20160816; b=c0KM4DjmIdJ4QA1Ta7tcaFhRaY4plczXnZ/OmqewatBlOCYZDB3q7dYkC8r+TMGce3 7xfWXiykfkMeSNX14D+Sxf5mbvcxMvECUlS2R7lRVB0gU2iwlQgdsK1wDSCH+poMiSiS XJELdHV7K2zFCQq2xymya5mOsQ4DfsUiPUIQ/t0HGLcaVU28PBNGRxJs/HnkkXYdfcjt 8N4h/uvNS+9N1L7NpM9jzDXwNBxsoyH9JW+0h/cBJRYxccTeslxRvPVMRbYGqjq+eFi8 s/BWn58GB0RLXHInaEs3yXz0UgwikaYJb9/VhGMuYeM3W10dfiedcOHkVWtcWxwVbtwn gMDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=sCvpBz1ca3/UGKq+qhCHCbH7g/uBx3+yyDitN7JhT+w=; b=cN6vQpAoV+SYwTNLZdEwPBlRnNDUjCugwuYMf0ZUiHKwQcTuMAs5Ds07kIa3A7F5W7 vKWj3PNHo0QdKCx5Us1ijmLWVfDF4zb6pMAR1rOsbhyFRxN+19c+9MzmmHRJgfV9v6Te IKb38CczgB3zWaGI1b6ARnrwZ6rZmJ+FTtgn+VJ8N2QlrC3y1YhRC7n8xl+Nx/pnx0Os TAQcxZghZBALbFoEYjogGbshSLDDALUpFW19S7UQ0cdFFXwYdgoqMJNL4x4eQbPrAtqE YF/lam0bI7zMiwFtjsE76IDH3du9Cn50Dlxxu/eKCmzn4HyT9baASvtrU81z+bUx4qTa 1jnA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x88si527775ede.291.2020.10.14.14.46.00; Wed, 14 Oct 2020 14:46:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727649AbgJNNo6 (ORCPT + 99 others); Wed, 14 Oct 2020 09:44:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:58152 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726459AbgJNNo5 (ORCPT ); Wed, 14 Oct 2020 09:44:57 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A9B842076D; Wed, 14 Oct 2020 13:44:55 +0000 (UTC) Date: Wed, 14 Oct 2020 09:44:53 -0400 From: Steven Rostedt To: Sudip Mukherjee Cc: Zamir SUN , Tony Jones , Jiri Olsa , LKML , Linux Trace Devel , Arnaldo Carvalho de Melo , "Ziqian SUN (Zamir)" , Vitaly Chikunov , Tzvetomir Stoyanov , Yordan Karadzhov , Ben Hutchings , John Kacur , Clark Williams , Al Stone , Mauro Carvalho Chehab Subject: Re: [ANNOUNCE] libtraceevent.git Message-ID: <20201014094453.73f37dd4@gandalf.local.home> In-Reply-To: References: <20201007130750.49349844@gandalf.local.home> <20201012101208.GF1099489@krava> <20201012111950.55a73588@gandalf.local.home> <20201012184120.GN13697@suse.de> <20201012151732.6e439886@gandalf.local.home> <20201013090228.78256290@gandalf.local.home> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 14 Oct 2020 11:08:48 +0100 Sudip Mukherjee wrote: > Just a thought, if you see > https://repology.org/project/linux-tools/versions then you will notice > that libtracevent has been packaged by the distros with a version of > v5.x+, and I will have the same problem for Debian also. Do you think > it makes sense to start with a version of v6.x when you tag it? If > that is not possible then we will have to use epoch like we did for > libbpf. Grumble. This is another reason I wish this was not part of the kernel. It should not have a versioning based on the kernel. Yeah, this may be an issue, especially, since library versions have real meaning with respect to compatibility, where the Linux kernel version numbers do not. We may need to use the epoch on this, because 5.7 has no meaning compared to 5.8 and 5.9. I didn't even realize this was being shipped yet. Yeah, I want to make this 1.1.0 as I've been tracking changes internally with this. -- Steve