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.8 required=3.0 tests=BAYES_00, 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 9ED6E1F55B for ; Thu, 4 Jun 2020 20:14:19 +0000 (UTC) Received: from localhost ([::1]:41136 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgwFm-0008Ju-Ij for normalperson@yhbt.net; Thu, 04 Jun 2020 16:14:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48480) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgwFi-0008F6-SQ for bug-gnulib@gnu.org; Thu, 04 Jun 2020 16:14:14 -0400 Received: from sprint-2.amdmi3.ru ([2a0a:2b41:94:cb5e::]:20000) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgwFh-0003Bt-Fy; Thu, 04 Jun 2020 16:14:14 -0400 Received: from amdmi3.ru (localhost [127.0.0.1]) by sprint-2.amdmi3.ru (Postfix) with SMTP id 4D5C03D3C3E; Thu, 4 Jun 2020 23:14:09 +0300 (MSK) Received: by amdmi3.ru (nbSMTP-1.00) for uid 1000 amdmi3@amdmi3.ru; Thu, 4 Jun 2020 23:14:09 +0300 (MSK) Date: Thu, 4 Jun 2020 23:11:20 +0300 From: Dmitry Marakasov To: Paul Smith Subject: Re: Versioned releases Message-ID: <20200604201120.GG11553@hades.panopticon> References: <20200604154144.GB11553@hades.panopticon> <1941801.zvzjLHy5AZ@omega> <1b0a905eb02c45c8d0c32aff60b05adf989cbd97.camel@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1b0a905eb02c45c8d0c32aff60b05adf989cbd97.camel@gnu.org> Received-SPF: none client-ip=2a0a:2b41:94:cb5e::; envelope-from=amdmi3@amdmi3.ru; helo=sprint-2.amdmi3.ru X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/04 16:14:09 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, NO_DNS_FOR_FROM=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, Bruno Haible Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" * 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. 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. With that, library code may be safely (even automatically) updated to the latest 1.x version, be it a systemwide package maintained by someone else, or a bundled code/subrepository, and consumer code will not break, yet having all the latest features/fixes from the library. > 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. 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. If you're going to introduce a version, please be sure it's the same being a tag or embedded in the source. You may as well embed git commit or `git describe` output, but it should be clearly separated from the version. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: https://github.com/AMDmi3