Re: Structured Changelogs for ELPA packages

Philip Kaludercic <[email protected]> writes:

> Daniel Mendler <[email protected]> writes:
>
>> Philip Kaludercic <[email protected]> writes:
>>
>>> So I think we should veer this conversation back to the question of
>>> whether (actual) package maintainers would be OK with specifying a
>>> strict format for NEWS files, with some fixed changelog heading style as
>>> was previously mentioned, or if no agreement is viable and we should
>>> instead try our best server-side to detect sections in as many file
>>> formats as possible.
>>
>> My opinion is that it is better to do our best to support multiple
>> possible formats, or simply rely on the git-based mechanism, which I had
>> already described and which avoids fixing a format.
>>
>> I am a package maintainer and I maintain numerous changelogs, and then I
>> am a user of multiple packages. As a maintainer, I want to keep the
>> format I am using right now (Towncrier-like). As a user I would like to
>> read changelogs from other packages, and I don't want to convince
>> package maintainers to change the format they've used for years. While
>> consistency is good, I am glad if package maintainers provide changelogs
>> at all and there are more important things to do.
>>
>> However if there is still interest to only want to support a list of
>> fixed formats, I suggest to support Towncrier-variants ("* <version>
>> (date)" and maybe variants like "* Version version (date)") and Keep a
>> Changelog "* [version] - date". Note that some package authors still use
>> other styles (e.g. packages by Jonas and Prot). Maybe these styles could
>> be supported too. I see nothing wrong with supporting multiple styles.
>> There is lots of precedent already, think about error messages in
>> compilation buffers for example.
>
> Supporting multiple formats of headings is the easier problem, a regular
> expression will be able to handle that.

Yes, this should work, as for example in the aforementioned compilation
mode. No problem at all to implement this, and also for Markdown, Org
and plain text.

> For me the question I am more fearful about is whether we want to
> support multiple _file_ formats. As we had mentioned, with Org it
> should be easy enough to extract the data since we have all the
> functions to do so in Emacs, but as soon as you add Markdown we'd have
> to implement some manual parsing and distinguish between different
> kinds of headings, detect section endings on our own, which feels like
> a nuisance just thinking about it.

I don't see why we would want to prescribe the package maintainers which
format to use. Instead of being thankful that package maintainers
maintain changelogs after all, we ask them to change their ways. In any
case, I am skeptical about this. I'd rather use what we've got and do
the best with it.

We should try the approaches and we will see that it works. For instance
the git approach. This has also the advantage that more of the latest
version is part of the feed entry, as Stefan had mentioned.

If you find this solution too ad-hoc (or dislike the imprecision), we
can go with the regexp approach and test it against various file formats
present on ELPA. I would exclude some of the outliers, but I would vote
that the most popular formats should work. Also, if implemented well,
the regexp list can be extended easily so there is no problem to add
more formats if someone requests it, at least as long as the format is
somewhat regular.

>> Daniel