code freeze lifted, and groff 1.24.1 and 1.25.0 release plans

"G. Branden Robinson" <[email protected]> Sat, 7 Mar 2026 21:35:48 -0600

Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260308033548.25jgbnkakbuhf6o4@illithid>

Hi folks,

We're one week out from the 1.24.0 release, which has been largely
successful; about 15 distributions are carrying it per repology.org,[1]
and the Savannah bug tracker has not been bombed insensate by reports of
difficulties with it. Even HP-UX 11.31 for IA-64 (Itanium) has 1.24.0.
For a purportedly dead OS[2] on a purportedly dead machine
architecture,[3] that's twice in a row they've gotten a new groff
release integrated within mere days of upload.

I guess rumors of death really do get exaggerated.

In other news:

I plan to do a point release on or about 14 March.

The reason is that I made a boo-boo that some of you will have already
noticed.

https://savannah.gnu.org/bugs/?68115

Since tagging 1.24.0, I've been pushing only documentation (and other
non-code) fixes to the master branch, so those will be swept up in the
point release as well.

Why wait another week?

1. More issues warranting a point release could arise. None of Debian,
Fedora, or openSUSE have yet packaged groff 1.24.0, and as these
distributions have large user bases, if they get that done in the
next few days, something troublesome might come to light.

2. I might find other ways to improve documentation.

Because of the (highly) constrained nature of the changes, I don't plan
to issue release candidates for 1.24.1. If anyone (including me)
commits a "thawing" change to the master branch, changing C/C++ or macro
package logic, I'll simply create a new branch from the previous commit.
Doing so might prove fortuitous anyway in the event we find ourselves
needing to release a 1.24.2.

And for groff 1.25, I still want to do a time-based release, eschewing
release goals in favor of shipping whatever good stuff gets done in
time. Four weeks of release candidates in the field seem ample.

It may even be too long a time--if anyone had tried groff 1.24.0.rc3 or
.rc4 with a man(1) pipeline that ran neqn(1), we'd have caught bug
#68115 while still in the pre-release phase, but apparently no one did,
or it only affected a few man pages. I recall reading something that
suggested the latter here:

https://bbs.archlinux.org/viewtopic.php?id=312465

...but I can no longer fruitfully access that URL. (Have the censors
struck?)

So I'd like to aim for a C/C++ code freeze on or about 3 June, followed
by an all-other-code freeze on 17 June, and shoot for a final release on
or about 1 July.

The fruits of that effort will inform plans for a groff 1.26 release in
about December. And from there, as I've suggested before, I'd like to
shoot for a cadence of annual releases.

Thoughts? Objections?

Any _happy_ experiences with groff 1.24.0? :)

Regards,
Branden

[1] https://repology.org/project/groff/versions
[2] https://www.osnews.com/story/144094/hp-ux-hits-end-of-life-today-and-im-sad/
[3] https://web.archive.org/web/20190416110949/https://www.anandtech.com/show/13924/intel-to-discontinue-itanium-9700-kittson-processor-the-last-itaniums

signature.asc (application/pgp-signature, 833 B)