From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf0-f66.google.com (mail-lf0-f66.google.com [209.85.215.66]) by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id e25a939e for ; Tue, 17 Jan 2017 08:23:22 -0500 (EST) Received: by mail-lf0-f66.google.com with SMTP id x1so10960606lff.0 for ; Tue, 17 Jan 2017 05:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=i3wm-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=jpR8HqDHxfgsF9FRvZyXpot3PyqWk3QUkAbNxqQ5B0I=; b=GcYSPLFOjlQ/eXN04LruRcnrTltwEQJ8q0Q5y+/ytmrdc4BLrloF76b0OIQBmijtnC QLQzoPKtf2zrjbJjWjMOlLK/umuPIO4rN4guLEIz29rp05yw+wA5eStxFKClfkOeD5BF m4xGx+Mn8qJrGIo1QLc72o8PYZJwQa4UYkHdSt8jGa+W4s/2MXB5sK0khyd74FSwAuYN +WDy2Auw/eKGC9JxeDa4bbtnksCwIyXOMXJm7yDZecIAn4ilSNBaXtZiZTvgltvJB0iG FbrFVGOabv2bHX+GRPk1NAGFssKXSiyLN02Sw96ospvALVVUkC5qQkAo+pvJTQ/TpaTE WXsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=jpR8HqDHxfgsF9FRvZyXpot3PyqWk3QUkAbNxqQ5B0I=; b=dmYKTq364yvJfh2Dk3e2s8Im++f3PUJ/k1J6D3yM0RnCtp9EBfgChU1p8fMR48DdnK Pnt8yd8+9n582iVCocNiyrVZDLk07zI+Zn2XP/+bzKtn/TDlFegO+Q6HX7AVg0nGVV3W gOIAZDskJFGZw7pXi1H/yqt8iaF7Va6zHgQ3kERG2e/DmkQEIhkwfl55vBQa/jv00cp7 bfiku4zXuXqJxKd9n2rSe3pvj5QAP4Nj5QcDl9I9+dfIxY0Jcfs+nwyYmk6VTL/vuL2N GQTzvNJsO3oCsm63UFHOsutU6DSPQUF8SO6C31AW2IiKkrZq5dfDya7G9j+9DP1tISVN wUiw== X-Gm-Message-State: AIkVDXJQyW+GjyXTXHVTyM7vN77X0acJhFAflfO5z8Wyu9ePL2bfvpsoS3OSU1jF0KZakKu3E+oLwTxR4UVZ8A== X-Received: by 10.25.154.2 with SMTP id c2mr5478739lfe.71.1484659400268; Tue, 17 Jan 2017 05:23:20 -0800 (PST) X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Sender: michael@i3wm.org Received: by 10.25.216.206 with HTTP; Tue, 17 Jan 2017 05:22:59 -0800 (PST) X-Originating-IP: [2620:0:105f:315:fd00:5788:7af9:41c8] In-Reply-To: <20170117130902.GB40964@athene.usta.de> References: <20170117003727.GA87474@athene.usta.de> <20170117130902.GB40964@athene.usta.de> From: Michael Stapelberg Date: Tue, 17 Jan 2017 05:22:59 -0800 X-Google-Sender-Auth: H1gDTPSr5L8bj_LwbDRdgjFkw90 Message-ID: Subject: Re: [PATCH] Implement -v to display the current version and exit To: Ingo Schwarze Cc: tech@mdocml.bsd.lv Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Okay. Thanks for the extensive rationale. I=E2=80=99ll do what works best f= or you and not provide a version number. On Tue, Jan 17, 2017 at 5:09 AM, Ingo Schwarze wrote: > Hi, > > Michael Stapelberg wrote on Tue, Jan 17, 2017 at 08:28:48AM +0100: >> On Tue, Jan 17, 2017 at 1:37 AM, Ingo Schwarze wrote: >> > Michael Stapelberg wrote on Mon, Jan 16, 2017 at 09:29:07AM +0100: > >>>> When using mandoc's output in other services (e.g. a web man viewer), >>>> it would be beneficial to display the version of mandoc that is in >>>> use. > >>> Why? In particular in a web viewer, you would end up displaying >>> that to end users. They really shouldn't care. > >> End users might want to reproduce a rendering issue before reporting a >> bug. For this use-case, it seems useful to know the version which was >> used to generate the page. > > I still don't get it. If they report to the server operators, those > people will know the version they run anyway. If they cnsider > reporting to me, we have exactly what i don't want: I much prefer > a report "on http://foo.bar.com/pagename.3, rendering is broken as > follows" to "with mandoc-1.13.4" because in the former case, i can > check myself, and in the latter i'm clueless what is going on. So > the version number should *NOT* be in there. Or at least it must > state OS and packaging information, or it's worse than useless, in > particular for that purpose. > >> In my projects, when I was faced with this problem, I went exactly the >> other route: I find "latest version that's in FreeBSD 9" way to >> imprecise, > > Nothing is imprecise about that. I can easily see the exact source > code they have online. > >> and just have my build system embed the git version number. > > Well, embedding the bsd.lv CVS commitid would be a terrible idea > for the same reasons as embedding the release version string. > > Besides, OpenBSD and NetBSD use CVS (different versions), FreeBSD > uses SVN, DragonFly and illumos use git - consequently, i'm out of > luck regarding consistent downstream commitids. > >> This works really well for me, but distributions tend to not patch >> my projects. > > It wouldn't work at all for mandoc. All major users have patches. > The most important user (OpenBSD) uses -current rather than any > release. The second most important user (FreeBSD) often uses > something that is half-way betwwen the latest release and -current. > The third most important (NetBSD) has a heavily patched version - > not for very good reasons, but they *are* quite patch-happy with > respect to mandoc. > >> I still think it's valuable to have the upstream version number >> available somehow. If you don't want it to be considered as the >> primary source of version information, that's fine. > > Worse than that, it's misleading and caused real problems in the > past. > >> Would you be okay with making it available under a hard-to-discover >> flag name, e.g. --upstream-version, > > No. Long options are inacceptable. Besides, in interface design, > it is crucial to minimize the number of options. > >> accompanied by a message > > No. Programs should not be chatty, but concise. "Here is some > information, but do not use it" makes no sense. Not providing > the misleading information in the first place is clearly better. > > Besides, i see a contradiction there. On the one hand, you want > the information to be hard to discover; but then you want to > display it on the web? With the message? Where are web users > supposed to get the packaging information from? > > In the end, i think you should simply provide no version number > whatsoever. That's less work for you and also better for me in > case of bug reports because it gives a better chance that people > actually explain what they are looking at. > > Yours, > Ingo --=20 Best regards, Michael -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv