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:
>>>
>>>> Daniel Mendler <[email protected]> writes:
>>>>
>>>>> Philip Kaludercic <[email protected]> writes:
>>>>>
>>>>>>> But indeed, I wouldn't worry too much, and if the snapshot feeds are not
>>>>>>> great, so be it. I usually write "* Development" headers in my
>>>>>>> changelog, so if you scan for headers including the string "devel" it
>>>>>>> would work.
>>>>>>
>>>>>> To be clear, I was not thinking about just scanning headers, but using
>>>>>> `org-export-select-tags'.  We should probably get some Org people in for
>>>>>> ideas if we decide to go this way.
>>>>>
>>>>> Okay, yes, but I am not in favor of requiring :tags: in changelogs.
>>>>
>>>> I would be interested to hear why not.  It would of course not be
>>>> required in general, just to get the "better" changelog support
>>>
>>> In my opinion it is better to be more permissive, and not prescribe a
>>> fixed format, in order to increase adoption. Ideally this should just
>>> work. I have little interest in adapting my changelogs for instance, if
>>> a simple scan would just work as well. The scanner could be tested
>>> against a few changelog formats which are currently used by ELPA
>>> packages.
>>
>> OK, so this is the question it boils down to.  I think that it would be
>> good to raise this question among a wider group of package maintainers
>> to get some more feedback, otherwise this is just the perspective of a
>> package author and an archive maintainer (to exaggerate) that obviously
>> have different priorities.
>
> Of course, go ahead. All I hope is that we don't end up with an
> over-engineered format. I am not even sure if there is agreement on
> using Org, Markdown or plain text. As far as I know there are some lax
> standards for plain text change logs, but they are likely lacking in
> comparison with Org.

OK, I would start a thread on emacs-devel and then cross-post it to the
Fediverse for more comments.

>>> To be clear, this feature request is really a low priority detail, where
>>> the packaging infrastructure could be polished, hopefully with little
>>> effort. But if it means that we have to prescribe a rigid changelog
>>> format, create unnecessary churn, or if the implementation is too
>>> complicated on the ELPA side, I think we should not do it.
>>
>> I don't think that my suggestion is that rigid or controversial.  I just
>> say that .org changelogs that use a :release: tag to mark the headings
>> that describe the latest release are last release are used generate the
>> contents of the atom feed entry for that release.  The details are of
>> course up to discussion, but I am surprised that you anticipate that
>> using a tag would be that controversial.  To me, it seems easier than
>> having to deal with different kinds of headings
>>
>> * Version 1.2.3
>> * Release 1.2.3
>> * Release of Version 1.2.3
>> * The release of 1.2.3
>> * 1.2.3 Changelog
>> * Changes in 1.2.3
>> * Version 1.2.3 released
>> * Announcing Foo 1.2.3
>> * Announcing Foo 1.2.3
>> * New Version Bar (1.8.2026)
>> ...
>>
>> I would anticipate that whatever format we support, people will want us
>> to relax the format to support whatever their preferred style is, for
>> the sake of being inclusive, where each change might backfire and cause
>> more and more false positives.  All in all not the end of the world, but
>> if we can avoid this sticky situation by just saying "use a tag" then it
>> seems well worth it for me.
>
> 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.

>>>>>>>>> Daniel