[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [groff] I hate git-version-gen
From: |
Bertrand Garrigues |
Subject: |
Re: [groff] I hate git-version-gen |
Date: |
Fri, 16 Mar 2018 01:01:26 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Hi Ingo,
On Thu, Mar 15 2018 at 08:34:00 PM, Ingo Schwarze <address@hidden> wrote:
> Hi,
>
> git-version-gen is a very serious nuisance. It efficiently prevents
> any kind of reliable testing. It creates totally ridiculous version
> strings like "1.22.3.rc1.40-1327" which then get scattered all over
> the place, up to and including absurd directory names like
>
> .../share/groff/1.22.3.rc1.40-1327/font/...
>
> but that crap really invades *many* places. That way, it is basically
> impossible to do any serious testing not only because such nonsense
> causes any packaging system to blow up, but also because all the
> testing gets completely invalidated once we go back to a sane version
> name like 1.22.4. Because who knows whether files are still in the
> right places, modules can still communicate properly, and modules
> can still handle the radically changing version string? And no,
> invalidating all previous testing is not what you want to do as
> shortly as possible before release.
Sorry to hear that you were annoyed by that. I thought that having a
unique directory name in .../share/groff/ would not be a problem and
could help for example to detect a build regression where a file is no
longer installed (if for example you forgot to uninstall and have some
files from a previous build that are still there), but I understand that
it can make the comparison of 2 builds harder.
> Can't we just get rid of that bloat, statically set the version string
> to 1.22.4 right now, and have the benefit of being able to start with
> real testing? Even if a number of commits may still go in, the risk
> that they break something - almost certainly locally - is much smaller
> than the risk that the complicated version-gen machinery, which has
> tentacles almost everywhere, causes or hides fundamental issues,
> which will then fully impact the final release, and that only.
While I understand the problem of the install directory in
.../share/groff (we could easily change that by extracting the first 3
numbers to build the directory name), what's the problem with having the
various programs printing a unique version (for example with 'groff
--version')? Does this bring extra testing difficulties? Having a
unique version seems better when people report a bug (otherwise they
would just say "I'm using 1.22.3" or "I'm using groff from git").
Regards,
Bertrand Garrigues
Re: [groff] I hate git-version-gen, Werner LEMBERG, 2018/03/16