Replies: 2 comments
-
One alternative solution could be to add a subsection under changed, added or removed
Benefit: you see directly what happens with the dependencies. |
Beta Was this translation helpful? Give feedback.
0 replies
-
The reason for dependency upgrade/downgrade/removal is important. For this reason I prefer @lioman's proposal. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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
orDependencies Updated
.This section could be "optional" as if a project has very few changes in dependencies, it could put them under
Changed
.Imaginary example:
As for our "internal standard", we put added dependencies under
Added
and (seldomly) removed dependencies underChanged
. That's why we call our sectionDependencies Updated
.References:
Beta Was this translation helpful? Give feedback.
All reactions