will/github-changelog-generator
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update README.md (#490)

Browse Source
This commit is contained in:
fatData 2017-05-21 14:53:16 -07:00 committed by Olle Jonsson
parent 9bbfa3add5
commit 4798a8a3d8
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
README.md
View File

@ -26,7 +26,7 @@ GitHub Changelog Generator ![GitHub Logo](../master/images/logo.jpg)
**Fully automated changelog generation** - This gem generates a change log file based on **tags**, **issues** and merged **pull requests** (and splits them into separate lists according to labels) from :octocat: GitHub Issue Tracker.
Since now you don't have to fill your `CHANGELOG.md` manually: just run the script, relax and take a cup of :coffee: before your next release! :tada:
Since you don't have to fill your `CHANGELOG.md` manually now: just run the script, relax and take a cup of :coffee: before your next release! :tada:
>### *What’s the point of a change log?*
To make it easier for users and contributors to see precisely what notable changes have been made between each release (or version) of the project.
@ -104,7 +104,7 @@ since-tag=1.0.0
### GitHub token
GitHub only allows only 50 unauthenticated requests per hour.
GitHub only allows 50 unauthenticated requests per hour.
Therefore, it's recommended to run this script with authentication by using a **token**.
Here's how:
@ -208,14 +208,14 @@ An auto-generated changelog really helps, even if you manually fill in the relea
For example:
When I found a closed bug, it's very useful know which release fixed it.
In this case, you can easily find the issue by \# in `CHANGELOG.md`.
When you find a closed bug, it is very useful to know which release fixed it.
So that you can easily find the issue by \# in `CHANGELOG.md`.
- it's not quite as easy to find this in handwritten releases notes
- a generated file saves you the trouble of remembering everything;
sometimes people forget to add things to a handwritten file
Ultimately, I think GitHub Releases is ideal for end-users.
Ultimately, I think GitHub Releases are ideal for end-users.
Meanwhile, `CHANGELOG.md` lives right in the repository, with its detailed list of changes, which is handy for developers.
Finally, there's nothing wrong with using GitHub Releases alongside `CHANGELOG.md` in this combination.