From debbugs-submit-bounces@debbugs.gnu.org Wed May 26 10:08:08 2021 Received: (at 48667) by debbugs.gnu.org; 26 May 2021 14:08:08 +0000 Received: from localhost ([127.0.0.1]:49648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lluCe-0005d0-CL for submit@debbugs.gnu.org; Wed, 26 May 2021 10:08:08 -0400 Received: from h87-96-130-155.cust.a3fiber.se ([87.96.130.155]:54282 helo=mail.yoctocell.xyz) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lluCc-0005by-9z for 48667@debbugs.gnu.org; Wed, 26 May 2021 10:08:07 -0400 From: Xinglu Chen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yoctocell.xyz; s=mail; t=1622038078; bh=3cnz0xJFpy0nZA5eC/xEEtSU4U6sDv2dZxaZqdB19jw=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=dQYJ6VjFqZsp8sC7HUe68J/sawLyOtGprLRB1U+gVGLUJi9QN52zlAN2wcFdwpq/Q waPmRoyo4DvkpUF/J9ZTRM5xhF+CPmnvKf7LOaKVGQNgEOjtPFoRcbhxAHeC19DbID NA7RTc0rTh9UmMCzGbkaUZNBeP4hQUWtyBaV4Hm8= To: Nicolas Goaziou Subject: Re: [bug#48667] [PATCH] doc: Expound on how to specify the version of a package. In-Reply-To: <87tumphcey.fsf@nicolasgoaziou.fr> References: <06217762b07f95d2ba2d40277d010647a926df68.1622019402.git.public@yoctocell.xyz> <87tumphcey.fsf@nicolasgoaziou.fr> Date: Wed, 26 May 2021 16:07:55 +0200 Message-ID: <874kepy4ec.fsf@yoctocell.xyz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Wed, May 26 2021, Nicolas Goaziou wrote: > Hello, > > Xinglu Chen writes: > >> * doc/guix.texi (package Reference): Describe how packages that lack a release >> or are pinned to an unreleased version should specify the [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: yoctocell.xyz (xyz)] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 0.4 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS X-Debbugs-Envelope-To: 48667 Cc: 48667@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Wed, May 26 2021, Nicolas Goaziou wrote: > Hello, > > Xinglu Chen writes: > >> * doc/guix.texi (package Reference): Describe how packages that lack a release >> or are pinned to an unreleased version should specify the [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: yoctocell.xyz (xyz)] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD 0.4 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, May 26 2021, Nicolas Goaziou wrote: > Hello, > > Xinglu Chen writes: > >> * doc/guix.texi (package Reference): Describe how packages that lack a r= elease >> or are pinned to an unreleased version should specify the =E2=80=98versi= on=E2=80=99 field. >> Add documentation for the =E2=80=98git-version=E2=80=99 procedure. > > Thanks.=20 > > I don't know if all should be included in the manual (though I think > the `git-version' function definitely should), but I'll comment it a bit > anyway. > >> @item @code{version} >> -The version of the package, as a string. >> +The version of the package, as a string. If there are no releases of >> +the package, or a unreleased version is desired, the version should >> +contain @code{VERSION-REVISION.COMMIT}. @code{VERSION} is >> +@c TODO: 0.0.0 or just 0 ? > > @samp{@var{VERSION}-@var{REVISION}.@var{COMMIT}} ... @var{VERSION}... > > I think you should drop the "version 0" case altogether. I don't think > enforcing "0" or "0.0.0" does matter, and it adds noise to the > explanations. Makes sense, users can probably that out on their own. >> +@code{0.0.0} or whatever the latest version is, and @code{REVISION} is >> +the revision of the Guix package (@code{0} if it is a new package), >> +whenever the package is updated to a newer version the revision should >> +also be bumped. > > @var{REVISION} > > I think you need to explain why bumping revision is needed. > > Also, this is all specific to hash-based repositories. For example, SVN > uses monotonic revisions already, so none of the above applies to such > packages. I am not familiar with SVN, but I will look into it. >> @code{COMMIT} is the @dfn{commit} or @dfn{changeset} >> +corresponding to the version, it should only contain 7 characters. If >> +the fetch method is @code{git-fetch} (@pxref{origin Reference}), there >> +is the @code{git-version} procedure that makes it easier to specify the >> +version. > > @var{COMMIT} > >> +@example >> +(git-version "0.0.0" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05") >> +@result{} "0.0.0-0.93818c9" >> +@end example >> +@end deffn > > Here too, I think the special "0.0.0" case is misleading. > > Maybe @lisp is more appropriate than @example. Good point. Thanks for the review! --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmCuVjsVHHB1YmxpY0B5 b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x5eYEP/2UKukDv1Nm9eUGuwdtU5Svs2ZPn f+K7LFpzuijRzCbPPxKrf0vy6QBhLHJDjR6kuUkfgsApj4Bhy5coDxTIvM31EN4S aoo8rMeIyQx6mtNjxBD5stRt7ABVmcnavVGS0hb6Jbkvddwkj5tB6k1cadnYf3TR QKkl+CSCGS2my7b4l9+2tFSw+AAkkTLJz9pYOjt63fZIlOH/R6lJZCXRfCuPBXrE FxiCoCSFnUmb0YRBTb/SKDolBM+DreTP4cUyU/ksMCPjC01vX6rEH2EU5RBMjZ5I lOZWrraLD2NCRR3s26G2Mke0X66n7usfOHG5bHtOp5WQY7vFaduxmMk0Optn21Ar HgZRdXaHtqQmdDZu00lP4+tseip+F1HQ7AeE7Aj3uh7ivXg79CexZ4J2dpiZ0bcc J+W8+74H10zboqnb07rc79yb4p/k2NU9FoSsL4S76ag+Rwhad8+2mSU0GDlZ83uG niJ2JkAk7XT5onRtvxLbs0Ns8KbprhCKqMZNj7gEdCakkPkQrA6L3qhPtBLQL8zo IcT90c6I9c9aI5K896hRyUBwAnRHkbNln8p5xEdnyxmCxc/amGn80ioStsoBaikh Ds0W/G6qFIkMyDu5430xGWTYNUUkb+0K4DJx5gN4KocjQng6dK2nNTCDhayk1ect 3puTS1I9r3YF0n02 =v8xw -----END PGP SIGNATURE----- --=-=-=--