Re: Structured Changelogs for ELPA packages

Philip Kaludercic <[email protected]> writes:

> "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.

I hope if we end up mandating (or strongly encouraging) a certain
format, it is one that the forges know how to render well.  For example,
the keepachangelog format is nice because its headings are clickable and
lead to a diff between the current and previous version.  Personally, if
I had to choose between a format that renders well in the browser and
one that makes it possible to have only the most recent version's
changes in the announce mail, I might stick to the former.