Re: Structured Changelogs for ELPA packages

"Dr. Arne Babenhauserheide" <[email protected]> writes:

> Philip Kaludercic <[email protected]> writes:
>
>> Stefan Monnier <[email protected]> writes:
>>
>>> FWIW, this whole discussion confirms my opinion tht we should stick to
>>> the simplistic approach we're currently using.
>
>> It saddens me to think that we could not do the "reasonable" thing,
>> avoid the noise, and just pick out the right section in the entry
>> announcing the release of say v0.13.7:
>>
>> --8<---------------cut here---------------start------------->8---
>> * v0.13.7   2026-08-06
>>
>> - Fixed a minor regression introduced in v0.13.6 affecting infixes
>>   whose values aren't represented using a string.
>> --8<---------------cut here---------------end--------------->8---
>
> I would like to see this “reasonable” version.
>
> Could it be opt-in? Define some formats and use them in the NEWS files
> that declare using them?

That was my idea.  For packages that follow some format, where we can
deterministically and reliably detect what section of the file
corresponds to at least the current release, we can extract the right
data.

The point of this thread is to find out what rules would be acceptable
to package maintainers, without creating too much complexity.

> Something like:
>
>> --8<---------------cut here---------------start------------->8---
> ## Recent NEWS:
>
> ;; -*- mode: outline; version-style: magit  -*-
> * v0.13.7   2026-08-06
>
> - Fixed a minor regression introduced in v0.13.6 affecting infixes
>   whose values aren't represented using a string.
>
> * v0.13.6   2026-08-01
>> --8<---------------cut here---------------end--------------->8---
>
> This would avoid breaking existing NEWS files and people who feel
> strongly about their format could contribute a style for that which they
> can then select.

Just to be clear that I am not missing something, the suggestion lies in
the version-style local variable right?

I don't know if that is necessary, since if we do go ahead with just
checking for headings that match a certain format (instead of, for
instance using explicit meta-data), we might as well just have a big
regular expression that matches all the known formats.

  (rx (or
       ;; Magit style
       (: "v" (group-n 1 (+ digit) (* "." (+ digit))) (+ space)
          (group-n 2 (= 4 digit) "-" (= 2 digit) "-" (= 2 digit)))
       ;; Keep a Changelog (https://keepachangelog.com/en/1.0.0/) style
       (: "[" (group-n 1 (+ digit) (* "." (+ digit))) "]" (+ space) "-" (+ space)
          (group-n 2 (= 4 digit) "-" (= 2 digit) "-" (= 2 digit)))
       ;; ...
       )
      (* space) eol)

This should work, unless there are overlapping interpretations between
the formats that somehow result in ambiguous parses, but I don't think
that is likely.
   
> Best wishes,
> Arne