From: Ingo Schwarze <firstname.lastname@example.org>
To: Michael Stapelberg <email@example.com>
Subject: Re: [PATCH] Implement -v to display the current version and exit
Date: Tue, 17 Jan 2017 14:09:02 +0100 [thread overview]
Message-ID: <20170117130902.GB40964@athene.usta.de> (raw)
Michael Stapelberg wrote on Tue, Jan 17, 2017 at 08:28:48AM +0100:
> On Tue, Jan 17, 2017 at 1:37 AM, Ingo Schwarze <firstname.lastname@example.org> 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
>> 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
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
> 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.
To unsubscribe send an email to email@example.com
next prev parent reply other threads:[~2017-01-17 13:09 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 [this message]
2017-01-17 13:22 ` Michael Stapelberg
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).