From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout-kit-02.scc.kit.edu (scc-mailout-kit-02.scc.kit.edu [129.13.231.82]) by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id 29b373f3 for ; Tue, 17 Jan 2017 08:09:09 -0500 (EST) Received: from asta-nat.asta.uni-karlsruhe.de ([172.22.63.82] helo=hekate.usta.de) by scc-mailout-kit-02.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1cTTVY-0004G6-99; Tue, 17 Jan 2017 14:09:08 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1cTTVX-0006Td-4Q; Tue, 17 Jan 2017 14:09:03 +0100 Received: from athene.usta.de ([172.24.96.10]) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1cTTVW-0002vu-Ub; Tue, 17 Jan 2017 14:09:03 +0100 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id 69e0c837; Tue, 17 Jan 2017 14:09:02 +0100 (CET) Date: Tue, 17 Jan 2017 14:09:02 +0100 From: Ingo Schwarze To: Michael Stapelberg Cc: tech@mdocml.bsd.lv Subject: Re: [PATCH] Implement -v to display the current version and exit Message-ID: <20170117130902.GB40964@athene.usta.de> References: <20170117003727.GA87474@athene.usta.de> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2 (2016-07-01) 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 -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv