Re: I'd like to help kill off some man(1) hacks

[G. Branden Robinson]

At 2020-08-24T22:47:05+0100, Colin Watson wrote:
> On Mon, Aug 24, 2020 at 04:39:32PM -0500, Dave Kemper wrote:
> > Does GNU in general, or groff in particular, have hard and fast rules
> > about what level of change warrants bumping which element of the
> > version number?  The next groff release will already change the
> > interpretation of some undelimited \s arguments (commit 0b9aaca0),
> > which has the potential to affect some back compatibility.  By the
> > strictest reading of the rules of semantic versioning
> > (http://semver.org/), this requires bumping the major version number.
> 
> groff hasn't generally done semver for this sort of relatively limited
> potential compatibility break, but I certainly think we shouldn't be
> scared of bumping the minor number.

While I'm willing to own up to breaking the world with the \s thing, I
don't think groff as a package or distribution is something to which
semantic versioning can be meaningfully applied.  The better-defined
your module boundaries are, the better semantic versioning can work.

groff, in terms of all the stuff we build and ship, is a fuzzy thing.

If we wanted to put a semantic version on the language that GNU troff
will accept, then that might be feasible (it could be exposed via a
string, for instance).  As I understand semantic versioning, this
question hangs on the issue of whether *roff, in anyone's dialect, but
particularly GNU's since that's what this list is for, is a decidable
language.  (Bash, rather notoriously, is not[1].)

So, any Haskell fans want to take up the challenge?  :D

[1] https://debconf18.debconf.org/talks/90-mining-debian-maintainer-scripts/

signature.asc
Description: PGP signature