-
Notifications
You must be signed in to change notification settings - Fork 264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CHANGELOG #176
Comments
I am all for this @rhuss. I assumed we’d reference it in release note. Did you want to add one for milestone 2 and we could all start editing it? |
@maximilien I just added a PR with #241 which includes all high-level items for 0.2.0 (hopefully I caught all of them). When 0.2.0 is out tomorrow, we can start a new "latest" section (or "pre-0.8.0") where we then add new for each PR. I could add a pretest check, that verifies that a PR number is included in the changelog file, so that one would then also have to add ignores PR in a comment section. |
Raised PR #242 which adds templates for github issues and pull requests, added a section for 'Release Note' in pr template, which can be used to write changelog / release notes. |
Fixed with #241 |
I suggest adding a simple changelog file so that people can easily see the content of each release. The benefit of a commit history that you can add the release versions (tags) with release date easily.
I set up a simple example at https://github.com/rhuss/client/blob/pr/changelog/CHANGELOG.adoc with the following characteristics:
I would do this manually as every automatic process would rely on a clean and clear naming of commits (which is really hard to enforce in community projects). However, I would add an integration test check for the PR URL to be added to the changelog, so that its not forgotten to get updated (PR by PR). For PR which are not changelog relevant we could allow the PR to be added in a comment section in the document (therefor I would write that Changelog in Asciidoc)
Some other real-world examples of manually maintained changelogs (grown over the years):
I'm all for keeping it simple but still manual (but checked by CI), as I never have been seen any good automatism for community projects without a strict commit policy.
The text was updated successfully, but these errors were encountered: