Hi Branden, G. Branden Robinson wrote on Fri, May 27, 2022 at 01:29:11PM -0500:
> Does anyone have any ideas for how we might surmount this issue? Certainly not by piling yet more overengineering on top of all the overengineering we already have. We don't need ten different ways to download and build groff. Having one way that is simple and reliable is better. For releases, tell people to download tarballs. They already work as intended, nothing to fix there. If people want to play with unreleased code, tell them to use git(1). It provides all kinds of useful functionality for that purpose (and more), for example switching to any desired commit. Supporting neither-fish-nor-fowl stuff is not only pointless but harmful because it wastes development time and introduces new opportunities for bugs. I already consider "git describe", "git-version-gen" and anything related to it as overengineering. When using a release, it is not needed at all. When an OS packager packages a release but applies a minimal set of OS-specific patches (which is very common and reasonable), it doesn't help at all because those patches are not in the groff git repo, so if the packaging system requires modifying the version number (usually by appending to it), packagers usually do that using tools specific to their packaging system. If somebody compiles from arbitrary git commits, *no versioning is needed* because such stuff is either needed only for development purposes or purely private. Stuff compiled from arbitrary git commits will never be used in packaging systems nor be distributed to end users. So this whole git-version-gen complexity solves an imaginary problem that does not exist in the first place. Its only benefits are being excessively complex and creating yet more imaginary follow-up problems like this one. Yours, Ingo
