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 1B5111F55B for ; Thu, 4 Jun 2020 19:46:41 +0000 (UTC) Received: from localhost ([::1]:52810 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgvp2-0006C8-5O for normalperson@yhbt.net; Thu, 04 Jun 2020 15:46:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46026) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgvoy-00069b-0n for bug-gnulib@gnu.org; Thu, 04 Jun 2020 15:46:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39193) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgvov-0006Zf-6X; Thu, 04 Jun 2020 15:46:34 -0400 Received: from pool-98-118-0-140.bstnma.fios.verizon.net ([98.118.0.140]:51432 helo=pdslaptop.home) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jgvor-0005Dl-Bo; Thu, 04 Jun 2020 15:46:32 -0400 Message-ID: <1b0a905eb02c45c8d0c32aff60b05adf989cbd97.camel@gnu.org> Subject: Re: Versioned releases From: Paul Smith To: Bruno Haible , bug-gnulib@gnu.org Date: Thu, 04 Jun 2020 15:46:21 -0400 In-Reply-To: <1941801.zvzjLHy5AZ@omega> References: <20200604154144.GB11553@hades.panopticon> <1941801.zvzjLHy5AZ@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 Cc: Dmitry Marakasov Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On Thu, 2020-06-04 at 20:19 +0200, Bruno Haible wrote: > Are you suggesting that every gnulib commit can be translated to a > version number? There's 'git describe' which does that. > > 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? What would be useful is if there were a "gnulib-version" module or similar that was constructed when bootstrap was run and pulled in a new suite of gnulib content, for example, based on the Git version perhaps. Then applications could call a C function to return the gnulib version as a string and include it in their --version output (if they wanted to) and users could judge the "freshness" of the gnulib content. For the distro packages, that take a snapshot of the Git repo: it would be good if there were some way to have that snapshot contain hardcoded version details from the Git, so that if apps bootstrapped from the distro snapshot of gnulib they would get the correct hardcoded version. I don't pretend to know too much about how all this works, including how distros create gnulib packages, but this seems like something that would be do-able and useful, and wouldn't need to involve any type of "automatic versioning" of gnulib in the Git repo. Regarding the format of the version: First, semver is not right for gnulib. The entire concept behind semver and similar versioning schemes is to use a version string to describe compatibility guarantees between different versions. That's (IMO) completely inappropriate for a source-only package like gnulib. I think the Git SHA is the single most critical element and must be included. However, it's not too informative unless the user has the Git repo. My recommendation would be to automatically add a tag once a month (say) to the gnulib Git repo with the date, and then use the "git describe" output as the version. This gives an easily-comparable version string with all the info needed.