[RFC] New, optional Section "Dependencies" or "Dependencies Updated"

[ravage84]

My team and I are "keep[ing] a changelog" according to this standard for years now. For our needs we have, though, adjusted the standard in a few regards based on our lessons learned.

One of those lessons learned is that the Changed section isn't practical for documenting changes in dependencies for larger projects.

For our web applications we regularly update the PHP dependencies through Composer & the JS/asset dependencies through NPM. Unsurpringly, this leads to large lists of changes we want to document because they can have an impact on the application. And that is one of the main reasons we keep a changelog, isn't it?

But why isn't it practical? Because these regular dependency updates, even tthough they are somewhat important, are distracting from the even more important changes that are normally filed under Changed.

By the way, the target audience of our change logs are developers, exclusively.

That said, I would like to propose a new section of changes named either Dependencies or Dependencies Updated. This section could be "optional" as if a project has very few changes in dependencies, it could put them under Changed.

Imaginary example:

## Version 1.1.9
### Dependencies
- cakephp/cakephp updated from 3.8.5 to 3.8.6
- cakephp/debug_kit updated from 3.20.3 to 3.21.0
- cakephp/chronos updated from 1.2.8 to 1.3.0

## Version 1.1.8
### Dependencies
- cakephp/cakephp updated from 3.8.6 to 3.8.7
- cakephp/migrations updated from 2.4.0 to 2.4.1
- cakephp/plugin-installer updated from 1.1.1 to 1.2.0
- league/csv updated from 9.4.1 to 9.5.0
- cakephp/bake updated from 1.11.2 to 1.12.0

## Version 1.1.7
### Dependencies
- cakephp/cakephp updated from 3.8.7 to 3.8.8
- friendsofcake/crud updated from 5.4.6 to 5.4.7
- league/flysystem updated from 1.0.61 to 1.0.63

## Version 1.1.6
### Dependencies
- cakephp/cakephp updated from 3.8.8 to 3.8.9
- cakephp/migrations updated from 2.4.1 to 2.4.2
- friendsofcake/search updated from 5.3.1 to 5.3.2
- cakephp/debug_kit updated from 3.21.0 to 3.22.1
- league/flysystem updated from 1.0.63 to 1.0.64

## Version 1.1.5
### Dependencies
- cakephp/cakephp updated from 3.8.9 to 3.8.10
- tecnickcom/tcpdf updated from 6.3.2 to 6.3.5
- league/flysystem updated from 1.0.64 to 1.0.65
- cakephp/debug_kit updated from 3.22.1 to 3.22.2

## Version 1.1.4
### Dependencies
- league/flysystem updated from 1.0.65 to 1.0.66
- cakephp/cakephp updated from 3.8.10 to 3.8.11
- robmorgan/phinx updated from 0.11.4 to 0.11.6
- cakephp/debug_kit updated from 3.22.2 to 3.22.3

## Version 1.1.3
### Dependencies
- league/flysystem updated from 1.0.66 to 1.0.67
- cakephp/debug_kit updated from 3.22.3 to 3.22.4
- cakedc/tiny-mce updated from 2.0.0 to 2.1.0

## Version 1.1.2
### Dependencies
- cakephp/cakephp updated from 3.8.11 to 3.8.12
- robmorgan/phinx updated from 0.11.6 to 0.11.7
- composer/composer updated from 1.10.5 to 1.10.6
- league/flysystem updated from 1.0.67 to 1.0.69
- friendsofcake/crud updated from 5.4.7 to 5.5.0

As for our "internal standard", we put added dependencies under Added and (seldomly) removed dependencies under Changed. That's why we call our section Dependencies Updated.

References:

• https://github.com/olivierlacan/keep-a-changelog/issues/20
• https://github.com/olivierlacan/keep-a-changelog/issues/33
• https://github.com/olivierlacan/keep-a-changelog/issues/272
• https://github.com/olivierlacan/keep-a-changelog/issues/234#issuecomment-447544222

[lioman]

One alternative solution could be to add a subsection under changed, added or removed

## Version 1.2.3 2020-11-10
### Changed
- Behaviour X is now Y
- Admin panel is painted red

#### Dependencies
- lib1 updated to 1.2.4
- lib2 updated to 4.2.1

### Removed
#### Dependencies
- lib3

Benefit: you see directly what happens with the dependencies. Drawback: It is more nested and if you only change dependencies for a patch release there are at least one useless line

[dolmen]

The reason for dependency upgrade/downgrade/removal is important. For this reason I prefer @lioman's proposal.