@cmderdev/trusted-contributors - What is the best way for us to handle CHANGELOG.md updates? I never really do a changelog because 'someone' does but I feel we could benefit from an agreed upon documented process.
Should we require all PRs to have an accompanying changelog.md entry adhering to: http://keepachangelog.com/en/0.3.0/
My latest PR description adheres to the above and I think it is a very readable and understandable description of both the PR, is relevant for the changelog.md and parts should even go in README.md.
Thoughts?
When I did one, I used https://github.com/skywinder/github-changelog-generator with the following settings:
user=cmderdev
project=cmder
unreleased=false
issues=false
between-tags=v1.3.4,v1.3.5
simple-list=true
token=<snip>
but it was meh. we close so many issues that allowing them to be included in automation would be just spam, maybe just when they were closed as fixed?
Otherwise we could use something like
#!/bin/bash
version=$( git describe --tags --always )
tag=$( git describe --tags --always --abbrev=0 )
if [ "$version" = "$tag" ]; then # on a tag
current="$tag"
previous=$( git describe --tags --abbrev=0 HEAD~ )
else
current=$( git log -1 --format="%H" )
previous="$tag"
fi
date=$( git log -1 --date=short --format="%ad" )
url=$( git remote get-url github | sed -e 's/^git@\(.*\):/https:\/\/\1\//' -e 's/\.git$//' )
title='# '${url##*/}
echo -ne "$title\n\n## [${version}](${url}/tree/${current}) ($date)\n\n[Full Changelog](${url}/compare/${previous}...${current})\n\n" > "CHANGELOG.md"
git shortlog --no-merges --reverse "$previous..$current" | sed -e '/^\w/G' -e 's/^ /- /' >> "CHANGELOG.md"
#git log --pretty=format:"###%s" "$previous..$current" | sed -e 's/^/ /g' -e 's/^ *$//g' -e 's/^ ###/- /g' -e 's/$/ /' >> "CHANGELOG.md"
#echo >> "CHANGELOG.md"
I was not even talking about an automated changelog based on git commit messages. Normally I say automate everything but to me automating a changelog based on git commit logs is almost meaningless spam.
I guess I was suggesting a human written changelog entry and version bump for each PR. If not that's fine, just looking for more meaningful data in that file.
Oh sure, I was just always too lazy. Ideally one would write a meaningful entry with every release, especially the next one with your PR will solve a lot of issues so you might want to do that one yourself?
I can do that. In my PR so let's not merge it yet. If we do a changelog entry and a version bump with every or then there is no changelog management at release. Every or to master is a release.
Hey @Stanzilla @daxgames we had the exact same thoughts like you had. We solved it by writing changelog annotations in the PR description. Afterwards the changelog gets generated automatically by a github app we are currently developing. If your interested in trying it out, it's free for open source repos and we would appreciate your feedback: changelox.com
Most helpful comment
I can do that. In my PR so let's not merge it yet. If we do a changelog entry and a version bump with every or then there is no changelog management at release. Every or to master is a release.