Re: [PATCH] Implement -v to display the current version and exit

[Michael Stapelberg <stapelberg@debian.org>]

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 <schwarze@usta.de> 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 <schwarze@usta.de> 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



-- 
Best regards,
Michael
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv