mirror of
https://github.com/ElectronNET/Electron.NET.git
synced 2026-02-04 05:34:51 +00:00
Add commit hash to items added to CHANGELOG.md
#62
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 installon start when node_modules directory already exists", but I can't see what was done to bring upon that change, code-wise.@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?
@yeskunall commented on GitHub (Nov 9, 2017):
I haven't come across a
CHANGELOGas 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.@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?
@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 hereAt 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
CHANGELOGand 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.
@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?
@yeskunall commented on GitHub (Nov 9, 2017):
Go ahead. Looking forward to the next release!