keep-a-changelog
chronicle
keep-a-changelog | chronicle | |
---|---|---|
10 | 2 | |
5,924 | 42 | |
- | - | |
7.8 | 8.5 | |
10 days ago | 3 days ago | |
Haml | Go | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
keep-a-changelog
-
Common Changelog
A style guide for changelogs, adapted from and a stricter subset of [Keep a Changelog](https://keepachangelog.com/)
- How do you handle API documentation and change logs?
-
What is your favorite method to take internal notes/documentation about the projects you build?
not entirely related to your question, but worth a read : https://keepachangelog.com/
- The Subtle Art of the Changelog
-
Product development guide #1
A Changelog should be written for each release, conforming to the standard https://keepachangelog.com/
-
Git log is not a changelog
I agree, I used to have a NEWS file in my projects (later a NEWS.md), but as others commented, the signification of the term "changelog" has changed. Sites like https://keepachangelog.com/ really refers to release notes or news.
- How do you manage your changelog sections?
-
Ask HN: What Makes a Good Changelog?
Overall I like the format and advice from https://keepachangelog.com/
We’ve adopted it at work and it’s nice to have a consistent format that is relatively noise free.
-
Semantic Versioning and Changelog
You can read more about it at: https://keepachangelog.com/
-
What is a Changelog and how to write one?
# Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ## [0.0.4] - 2014-08-09 ### Added - Better explanation of the difference between the file ("CHANGELOG") and its function "the change log". ### Changed - Refer to a "change log" instead of a "CHANGELOG" throughout the site to differentiate between the file and the purpose of the file — the logging of changes. ### Removed - Remove empty sections from CHANGELOG, they occupy too much space and create too much noise in the file. People will have to assume that the missing sections were intentionally left out because they contained no notable changes. ## [0.0.3] - 2014-08-09 ### Added - "Why should I care?" section mentioning The Changelog podcast. ## [0.0.2] - 2014-07-10 ### Added - Explanation of the recommended reverse chronological release ordering. ## [0.0.1] - 2014-05-31 ### Added - This CHANGELOG file to hopefully serve as an evolving example [Unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.4...HEAD [0.0.4]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.3...v0.0.4 [0.0.3]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.2...v0.0.3 [0.0.2]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.1...v0.0.2 [0.0.1]: https://github.com/olivierlacan/keep-a-changelog/releases/tag/v0.0.1
chronicle
-
Git log is not a changelog
we use https://github.com/anchore/chronicle to generate release notes in a changelog format using the issues and PRs from GitHub as the source of truth. In this way time well spent in the curation of issues and PRs (which is something we need to do anyway) means that we automatically get release notes for free. (disclaimer: I'm the author of chronicle)
-
Keep a Changelog
The approach I like to take is to curate issues and PR with semantic titles and organize them by label ("bug", "enhancement", etc) or linking PRs to an already curated issue. This way automation can use these to generate the changlog for me on each release based on closed issues and unlinked PRs since the last release.
We wrote Chronicle to do that automation for us: https://github.com/anchore/chronicle .
The nice thing about this... since you typically curate issues during the development process anyway, if you're doing that right then you get a nice looking changlog for free! We use this approach with our core tools, Syft and Grype (some changlog examples: https://github.com/anchore/syft/releases/tag/v0.31.0 and https://github.com/anchore/grype/releases/tag/v0.26.1 ).
Always happy to hear new feature ideas and possible customizations for Chronicle (put in an issue and let's chat )!
What are some alternatives?
conventional-changelog - Generate changelogs and release notes from a project's commit messages and metadata.
semantic-pull-requests
standard-version - :trophy: Automate versioning and CHANGELOG generation, with semver.org and conventionalcommits.org
chyle - Changelog generator : use a git repository and various data sources and publish the result on external services
semver - Semantic Versioning Specification
jrnl - Quick and easy CLI journaling tool for Github wiki journals.
git-quick-stats - ▁▅▆▃▅ Git quick statistics is a simple and efficient way to access various statistics in git repository.
semantic-pull-requests - :robot: Let the robots take care of the semantic versioning
Release It! 🚀 - 🚀 Automate versioning and package publishing
pyroscope - Continuous Profiling Platform. Debug performance issues down to a single line of code [Moved to: https://github.com/grafana/pyroscope]
tag - Git utility to create tags in order to identify specific releases
release-please - generate release PRs based on the conventionalcommits.org spec