bug#81116: 31.0.60; [FR] ELPA: Include changelog in the Atom feeds

Philip Kaludercic <[email protected]> writes:

> Daniel Mendler <[email protected]> writes:
>
>> Philip Kaludercic <[email protected]> writes:
>>
>>>> I am not sure I see the problem you're trying to solve. When we know the
>>>> version 1.2.3, we can simply scan all headlines for 1.2.3, take the
>>>> first headline and we will be good?
>>>
>>> Then you have a subsection in underneath the section in 1.2.4 titled
>>> "Bugfixes since 1.2.3" and we accidentally pick up on that instead.  It
>>> is my experience that we are just inviting annoyances like this if we
>>> start with the flexible approach, which undermines the intention of
>>> providing the right changelog information for each release.
>>
>> This won't happen in the scheme I had in mind. When you scan for 1.2.3
>> you must take the changelog from git corresponding to version 1.2.3, and
>> there won't be a "since 1.2.3". However you have to check out the
>> changelogs for all the versions you want to include in the feed, for
>> instance the ten last versions, but this should be efficient enough.
>> Another alternative would be to detect the indentation depth from the
>> latest version and then only scan headings of the same depth for the
>> older version numbers.
>
> In any case, my argument is that this all sounds much more complicated
> (from our side) than requiring the package author to use org-mode and
> annotate the relevant section with a tag.  But I have now posted a
> thread on emacs-devel, so I think the discussion should continue there,
> and when we have a satisfactory/popular solution, we can return to the
> problem of including changelogs in the Atom feeds.

Yes, I see where you are coming from. But your approach is strictly
speaking not correct. Feed entries which have already been published
should not change again. They are basically immutable and feed readers
will not refetch them, as long as their ids do not change. The ids
should also be stable since otherwise feed readers end up with duplicate
entries. This means that one has to derive the entries from the
changelogs extracted from the specific versions in git. Given these
constraints I don't see anything wrong with the scanning method.

Daniel