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
