From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id F27B61F55B for ; Thu, 4 Jun 2020 21:29:25 +0000 (UTC) Received: from localhost ([::1]:47868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgxQS-0005D5-Qa for normalperson@yhbt.net; Thu, 04 Jun 2020 17:29:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60342) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgxQO-0005Cn-VG for bug-gnulib@gnu.org; Thu, 04 Jun 2020 17:29:20 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.20]:19508) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgxQM-00031v-HD for bug-gnulib@gnu.org; Thu, 04 Jun 2020 17:29:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591306155; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=1H6SCfU/t1JHVQcy0/0SXTyhiRUJxG1lNBpTYBNJz3Y=; b=piTW8jYZIEnU/3AA/iCHXYl91RaWXd1HZ/uqciU1BVAZaDjeTerNestAWxo/J2S9C0 /DItbcjnXxqMaKLG7/p2QNfewUrkG27fY4X8EX7l/+XWKqKTl/z7QWTyele0qGOg01s8 gemG9o+SjMDVTc5jc8kwDRBId+RCjXxdQCWOfqtn00wHihV3jYKG+vUogxkfpoGBsLJ1 MwY6NTotySfd28PHzQ+RakWMaRRANEF6/KCcG89WaY2yMyNcJJ1AabXJY9mFcF9FDxA+ hjHgIvPVbcF4kV6O5DT56cJczXWp+abT9RvqmYLxGnvBMGeswY2iEsGAq4NvAbE8lSC/ bk+A== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOH6fzxfs=" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 46.9.1 DYNA|AUTH) with ESMTPSA id V0a757w54LTEC6l (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Thu, 4 Jun 2020 23:29:14 +0200 (CEST) From: Bruno Haible To: Dmitry Marakasov Subject: Re: Versioned releases Date: Thu, 04 Jun 2020 23:29:14 +0200 Message-ID: <1911602.eSSrpkIMfF@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-177-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20200604192914.GE11553@hades.panopticon> References: <20200604154144.GB11553@hades.panopticon> <1941801.zvzjLHy5AZ@omega> <20200604192914.GE11553@hades.panopticon> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=85.215.255.20; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/04 17:29:15 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Hi Dmitry, > My claim only covers standalone distribution of gnulib. I don't want > to dig into the reasons for why upstream forces bundling and why > downstream don't follow it anyway, but the sole fact that it's packaged > standalone in so many distribution speaks for itself of that this way of > distribution is a necessity. I don't think so. This way of distribution is a misunderstanding. Every developer nowadays is used to doing 'git clone' here and there; there are even more and more people who prefer the hassles of building a package from a git checkout to the sailing trip of building a tarball. > With standalone distribuition there's no way to peek into git history > or some source files, but there's a clear identifier of which specific > version is packaged. Yes. As I said, the first line of the ChangeLog is the best identifier. > > Or are you suggesting that the Gnulib developers pick, say, every 100th > > Gnulib commit and assign it a version number? And how would that be useful, > > since the consumers upgrade when they like to? > > I would suggest using proper semver. semver is not a good philosophy for gnulib, because different packages use different gnulib modules. This week we made an incompatible change to the 'read-file' module; but the vast majority of the packages will not be impacted because they don't use this module. Therefore bumping a version number is not really meaningful. > But dumb tagging every nth > commit, or weekly or so would definitely be better than nothing I disagree on this one. It would make people think that the Nth commit, or the Monday commit, or whatever, is preferred over the other commits. Which it really isn't - there may be a regression fix coming in just the next day. In summary: * The date (first line of ChangeLog) is a good version indicator. * If someone doesn't like dates, for whatever reason, they can use 'git describe'. Bruno