Split up changelog

[jacob-carlborg-apoex]

When I update a version of a dependency I'm interested in knowing how it can affect my application. Primarily I'm interested in knowing if updating the dependency can break something. Secondarily I'm interested in knowing about new features. I'm usually not interested in knowing about internal changes or changes that doesn't affect the code.

In my opinion the ViewComponent changelog is a bit noisy, making it more difficult to figure out if and update is safe to do. I'm not interested in knowing if a typo has been fixed in the documentation, if an additional company is listed on the web site or if the project has started using a different CI system. These are not changes that I would personally include in any of my own open source projects. I'm interested in knowing about methods being removed, added an so on. Currently all these type of changes are at the same level in the changelog, all of them are equal.

I suggest that if ViewComponent wants to keep this kind of information in the changelog that the changelog entries for a given version is split up in multiple sections, grouping what kind of changes they are.

Here's a suggestion on how a changelog can look like [1]. Although what's missing from that page (that can be useful for ViewComponent) are an "internal" section and a section not related to code, i.e. documentation and the web site.

[1] https://keepachangelog.com/en/1.0.0/

[joelhawksley]

@jacob-carlborg-apoex I think this is a fair criticism. I've leaned toward recognizing all contributions to the project, no matter how small. I like the idea of splitting up the entries to have changes that do not affect the published gem broken out 👍🏻