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

Daniel Mendler <[email protected]> writes:

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

I do not get why tagging or scanning would make a difference here.  The
question here is only how we detect and extract a section, what we do
with the section contents afterwards, and how we process that into the
atom feed, is unrelated.

> Daniel