Add commit hash to items added to CHANGELOG.md #62

Closed
opened 2026-01-29 16:29:37 +00:00 by claunia · 6 comments
Owner

Originally created by @yeskunall on GitHub (Nov 9, 2017).

Originally assigned to: @robertmuehsig on GitHub.

Hey guys 👋

Thanks for maintaining a changelog. Perhaps it'd be better if you could also introduce the commit hash. That way we (and you, as the developer) can precisely see what notable changes have been made between each release.

Right now, I know you "skip npm install on start when node_modules directory already exists", but I can't see what was done to bring upon that change, code-wise.

Originally created by @yeskunall on GitHub (Nov 9, 2017). Originally assigned to: @robertmuehsig on GitHub. Hey guys 👋 Thanks for maintaining a changelog. Perhaps it'd be better if you could also introduce the commit hash. That way we (and _you_, as the developer) can precisely see what notable changes have been made between each release. Right now, I _know_ you "skip `npm install` on start when node_modules directory already exists", but I can't see _what_ was done to bring upon that change, code-wise.
claunia added the In progress label 2026-01-29 16:29:37 +00:00
Author
Owner

@robertmuehsig commented on GitHub (Nov 9, 2017):

Good feedback - we are still learning how to do such a project on GitHub :)

Do you have a good example from other projects with a good Changelog?

@robertmuehsig commented on GitHub (Nov 9, 2017): Good feedback - we are still learning how to do such a project on GitHub :) Do you have a good example from other projects with a good Changelog?
Author
Owner

@yeskunall commented on GitHub (Nov 9, 2017):

I haven't come across a CHANGELOG as succinct and well-maintained as NodeJS. Here, have a look. Of course, with each project, the needs are a bit different, but hope this helps you out in some way.

@yeskunall commented on GitHub (Nov 9, 2017): I haven't come across a `CHANGELOG` as succinct and well-maintained as NodeJS. Here, have a [look](https://github.com/nodejs/node/tree/master/doc/changelogs). Of course, with each project, the needs are a bit different, but hope this helps you out in some way.
Author
Owner

@robertmuehsig commented on GitHub (Nov 9, 2017):

Ah - I see. Maybe if we would use the releases on GitHub it would also work, right? At least you would know the point in the we released v0.0.6 or v0.0.7, correct?

@robertmuehsig commented on GitHub (Nov 9, 2017): Ah - I see. Maybe if we would use the releases on GitHub it would also work, right? At least you would know the point in the we released v0.0.6 or v0.0.7, correct?
Author
Owner

@yeskunall commented on GitHub (Nov 9, 2017):

Yup, GitHub releases are basically git tags. Keep in mind tho, the release tab on GitHub does not replace the need for maintaining a CHANGELOG. As mentioned here

Releases are GitHub's way of packaging and providing software to your users. You can think of it as a replacement to using downloads to provide software.

At best, GitHub will pull annotated git tag messages and turn them into notes, or you could add them under the release notes yourself. If you're going to opt-in for the second option, maintaining a CHANGELOG and linking to it within each release should suffice.

But in the end, it all comes down to how the maintainers choose to do things. What I've stated above are merely my opinions, and are in no way a standard. Here's a neat little website that might answer most, if not all your questions about maintaining a changelog.

@yeskunall commented on GitHub (Nov 9, 2017): Yup, GitHub releases are basically git tags. Keep in mind tho, the release tab on GitHub does not replace the need for maintaining a `CHANGELOG`. As mentioned [here](https://help.github.com/articles/about-releases/) > Releases are GitHub's way of packaging and providing software to your users. You can think of it as a replacement to using downloads to provide software. At best, GitHub will pull annotated git tag messages and turn them into notes, or you could add them under the release notes yourself. If you're going to opt-in for the second option, maintaining a `CHANGELOG` and linking to it within each release should suffice. But in the end, it all comes down to how the maintainers choose to do things. What I've stated above are merely my opinions, and are in no way a standard. [Here's](http://keepachangelog.com/en/1.0.0/) a neat little website that might answer most, if not all your questions about maintaining a changelog.
Author
Owner

@robertmuehsig commented on GitHub (Nov 9, 2017):

Thanks for the suggestion! It's more or less the first GitHub project I'm working on with more then a few known users 😃

When we do the next release I will create a proper GH release and I will mark the current state as 0.0.7.

I would like to close this issue, but feel free to comment on it if we do something stupid, ok?

@robertmuehsig commented on GitHub (Nov 9, 2017): Thanks for the suggestion! It's more or less the first GitHub project I'm working on with more then a few known users 😃 When we do the next release I will create a proper GH release and I will mark the current state as 0.0.7. I would like to close this issue, but feel free to comment on it if we do something stupid, ok?
Author
Owner

@yeskunall commented on GitHub (Nov 9, 2017):

Go ahead. Looking forward to the next release!

@yeskunall commented on GitHub (Nov 9, 2017): Go ahead. Looking forward to the next release!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/Electron.NET#62