help / color / mirror / Atom feed
From: Michael Stapelberg <>
To: Ingo Schwarze <>
Subject: Re: [PATCH] Implement -v to display the current version and exit
Date: Tue, 17 Jan 2017 05:22:59 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Okay. Thanks for the extensive rationale. I’ll do what works best for
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, 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 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

Best regards,
 To unsubscribe send an email to

      reply	other threads:[~2017-01-17 13:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-16  8:29 Michael Stapelberg
2017-01-17  0:37 ` Ingo Schwarze
2017-01-17  7:28   ` Michael Stapelberg
2017-01-17 13:09     ` Ingo Schwarze
2017-01-17 13:22       ` Michael Stapelberg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).