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 A85D81F55B for ; Thu, 4 Jun 2020 21:16:16 +0000 (UTC) Received: from localhost ([::1]:39016 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgxDj-00082e-Gp for normalperson@yhbt.net; Thu, 04 Jun 2020 17:16:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56384) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgxDg-00082Q-1a for bug-gnulib@gnu.org; Thu, 04 Jun 2020 17:16:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40831) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgxDd-0008R7-4Y; Thu, 04 Jun 2020 17:16:09 -0400 Received: from pool-98-118-0-140.bstnma.fios.verizon.net ([98.118.0.140]:52088 helo=pdslaptop.home) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jgxDc-000730-64; Thu, 04 Jun 2020 17:16:08 -0400 Message-ID: <8f361db6bdadcf336a7253047d42fca4f296484d.camel@gnu.org> Subject: Re: Versioned releases From: Paul Smith To: Dmitry Marakasov Date: Thu, 04 Jun 2020 17:16:07 -0400 In-Reply-To: <20200604201120.GG11553@hades.panopticon> References: <20200604154144.GB11553@hades.panopticon> <1941801.zvzjLHy5AZ@omega> <1b0a905eb02c45c8d0c32aff60b05adf989cbd97.camel@gnu.org> <20200604201120.GG11553@hades.panopticon> 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: bug-gnulib@gnu.org, Bruno Haible Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On Thu, 2020-06-04 at 23:11 +0300, Dmitry Marakasov wrote: > * Paul Smith (psmith@gnu.org) wrote: > > > 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. > > Why, that's precisely what semver is useful and was designed for. > It's MAJOR.MINOR.PATCH - if you break API, bump MAJOR, if you > introduce new feature, bump MINOR, otherwise bump PATCH. I'm not a gnulib developer, so I don't want to speak for them: maybe they would like to make this attempt. But IMO it's not appropriate for gnulib. During the development of gnulib there aren't discrete release points where someone will stop and consider all the changes since the last release, and assign some version to it as a whole. To the extent that such discrete points exist they are invented by distributions that include gnulib as a package... not by the gnulib developers. To follow semver, or a similar versioning scheme, would mean that EVERY SINGLE COMMIT would have to change the version, because EVERY SINGLE COMMIT makes some change, and anyone could do a Git pull of gnulib at any instant and include it in their program, or in their distribution. The only possibly workable option would be to have the first two numbers in a semver be bumped by developers when they pushed changes which they knew to change the API or add a feature, and leave the last number to be automatically generated based on the number of Git commits since the last version bump (since those commits can be assumed to be bugfixes only). However, I doubt this is reasonable either. First, even only considering the first two semver values it would add a lot of overhead and effort to the development process to consider and get right these version bumps with every push to the repository. Second, remember gnulib is not a monolithic entity: it's a collection of 1,200 or so discrete "utilities" (and counting...), most of which are just one or two files. Do we say that the version of gnulib should change every time ANY ONE of those hundreds of utilities had a new feature or a change to their API? Suppose Bruno pushes a new module (second number bump), then the next day realizes it has a problem that needs the API to change (first number bump). Then an hour later he realizes there's another problem with the API (another first number bump). Etc. Just because the API version bumped doesn't tell you anything very interesting when it could be any one of >1000 different utilities whose API was changed, for any number of reasons. > So as a consumer I may just require e.g. version >=1.2.3 <2, and > expect it to be API-compatible and have all the features my code > requires. That isn't how gnulib is intended to be used. > > 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. > > This complicates the format, as SHAs are never appropriate in the > verions, for they are not monotonic and alphabetic characters are not > compatible with all package managers. Someone may include them, some > may omit them, and we'll end up with incompatible versioning schemes > again. IMO the idea of being able to learn anything from a gnulib version that is more informative than, "this one contains more recent commits than that one" is not feasible. But I think that "this one contains more recent commits than that one" _IS_ a very useful and desirable metric and speaking as a gnlib user I hope we can find a relatively painless way to incorporate it.