Re: groff 1.24.0.rc1 available for evaluation

"G. Branden Robinson" <[email protected]> Sun, 18 Jan 2026 15:40:13 -0600
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260118214013.pqt6rgfs3hb6sof4@illithid>
Hi Ingo,

At 2026-01-18T22:24:29+0100, Ingo Schwarze wrote:
> First problem report:
> 
> Extracting the tarball results in a directory
> 
>   groff-1.23.0.5077-7dcc8
> 
> which is inconsistent and confusing naming.  Obviously, this is
> trivial to work around in the port building system, but i consider it
> a defect nonetheless.

Yes, fair point.  I need to add something about this to the
"FOR-RELEASE" file.

I applied the tag in retrospect, having selected a "dist" archive that
built successfully on a handful of host configurations available to me.

I guess what I need to do in the future is apply the tag and then
re-roll the distribution archive.

> Logical directory names would be something like
> 
>   groff-1.24.0
>   groff-1.24.0rc1
>   groff-1.24.0.rc1
> 
> I think calling the tarball and directory "1.24.0rc1" would make more
> sense logically than "1.24.0.rc1" because "1.24.0" is the dotted
> version number and "rc1" is a suffix to it; "rc1" is not another
> number component of the version number.

That's true, but I find it important to distinguish this "fourth
component" of the version number from that stored in the `.Y` register,
and we've had problems in this area before.

I'm having trouble tracking down citations, but it back around
2017-2018.  I think a release candidate was put out and it broke weirdly
for some people because the interpolated contents of the `.Y` register
were not a simple integer.

> I'm planning to report problems as i go.  Based on past experiences,
> i expect to encounter a few dozen problems during testing, not
> counting problems that already existed in 1.23.  To make sure nothing
> gets lost, i intend to report one problem per mail as soon as i
> encounter it.  I'm not yet sure whether it's better to send mail
> only to you privately (as the effective release manager) or to the
> list.  Which option do you prefer?

Sending to the list is fine.  Maybe Dave can help convert some of them
into Savannah tickets.

> I'd don't categorically refuse using Savannah, but i'd like to avoid
> it as much as possible because using it is typically painful, slow,
> and error-prone.  Of course, if you need Savannah tickets, i can
> make them, in that case, just say so, either in general or for
> particular issues; i just don't want to cause a needless fuss.

We can judge things on a case-by-case basis.  Likely, anything that
would require a code change will merit a Savannah ticket.

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