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=-4.1 required=3.0 tests=AWL,BAYES_00, 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 F2C8A1F55B for ; Fri, 5 Jun 2020 12:16:03 +0000 (UTC) Received: from localhost ([::1]:33514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhBGU-0002HG-D0 for normalperson@yhbt.net; Fri, 05 Jun 2020 08:16:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58308) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhBGR-0002H5-4m for bug-gnulib@gnu.org; Fri, 05 Jun 2020 08:15:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34671) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhBGQ-0005Lz-SX for bug-gnulib@gnu.org; Fri, 05 Jun 2020 08:15:58 -0400 Received: from pool-98-118-0-140.bstnma.fios.verizon.net ([98.118.0.140]:36536 helo=pdslaptop.home) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jhBGP-0002he-TA for bug-gnulib@gnu.org; Fri, 05 Jun 2020 08:15:58 -0400 Message-ID: <7329895f19ebf597e212d6921fb36f9ca7eb5602.camel@gnu.org> Subject: Re: Versioned releases From: Paul Smith To: bug-gnulib@gnu.org Date: Fri, 05 Jun 2020 08:15:57 -0400 In-Reply-To: <1911602.eSSrpkIMfF@omega> References: <20200604154144.GB11553@hades.panopticon> <1941801.zvzjLHy5AZ@omega> <20200604192914.GE11553@hades.panopticon> <1911602.eSSrpkIMfF@omega> Organization: GNU's Not UNIX! Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: , Reply-To: psmith@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On Thu, 2020-06-04 at 23:29 +0200, Bruno Haible wrote: > 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. I'm not sure about that. A tag which is just the date is pretty clearly nothing more than that: a tag which is the date. I don't think anyone will somehow believe that it means more than it is. Plenty of systems out there do similar things. > 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'. IMO 'git describe' is less useful without some type of tagging regimen. Even tagging once a year would be helpful. This is today: $ git describe v0.1-3536-gd50852525 ?? If we added a tag "2020" at the beginning of the year we'd get: $ git describe 2020-427-gd50852525 A tag like "202006" the beginning of the month would be: $ git describe 202006-11-gd50852525 However it's done, my main hope is that gnulib provide some kind of module which does this version detection and generation for you, and builds that into its scripting so it's automatic, rather than everyone reinventing it (possibly slightly differently) for themselves. For example when I run bootstrap against a Git repo, it would run "git describe" and put the results into some gnulib version string in the files copied into my workspace. And there could be an "extract a static workspace" script that would do the same type of thing for an entire gnulib copy, that distributions (if they really wanted to ship a "gnulib" package) could run.