NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
pub.dev · #1731 most downloaded on pub.dev
Automatically increments, sets, prints the package version in pubspec.yaml. Adds, lists, prints entries in the changelog. Creates diff links in the changelog.
Last release 7 months ago
13 Feb 2026
Ships unpredictably
gaps range from 8 days to 1.5 years
Nearly every release is documented
notes for 27 of 28 stable releases
1 version withdrawn
withdrawn after publishing
6 years old
31 releases · first in 2020
One column per quarter.
Support custom tag naming by @davidmartos96 in #88
Full Changelog: 0.2.9...0.2.10
Added missing export: cli/channel.dart
Deps version bump and a minor refactor
What's Changed v0.2.7 by @f3ath in #74 Full Changelog : 0.2.6...0.2.7
Fix: Test setup does not await file copying by @marvin-kolja in #68
Full Changelog: 0.2.5...0.2.6
bump and log proper subcommands to improve UX (PR by marvin-kolja)### Changed - Bump dependencies
### Changed - Bumped dependencies
The Diff class had been erroneously put in lib. Moved back to src/ where it belongs.
Diff class had been erroneously put in lib. Moved back to src/ where it belongs.The --only-body option for the describe command.
--only-body option for the describe command."Error: No value found at /cider" when run with no configuration in pubspec.yaml
The list command to list all versions from the changelog.
list command to list all versions from the changelog.--project-root argument.Nothing published for this version
Nothing published for this version
Correctly abort upwards search for project root directory upon reaching filesystem root. (thanks @maltevesper)
Ability to yank/unyank specific versions
Bumped dependencies versions (thanks @zeshuaro)
Dependency on intl (thanks @zeshuaro)
### Added - Release promotion command
Nothing published for this version
### Changed - Updated dependencies
Support for pre-release version part.
Nothing published for this version
Ability to retain pre-release part of the version
Using a yaml manipulation library to updated pubspec.yaml. This expected to be more reliable than a regexp.
Using a regex instead of yaml parser to modify pubspec.yaml. This should preserve existing file formatting
Fixed \#1 by downgrading the path dependency
path dependency### Changed - Updated the dependencies
Minor documentation improvements
A changelog is a file which contains a curated, chronologically ordered list of notable changes for each version of a project.
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.
People do. Whether consumers or developers, the end users of software are human beings who care about what's in the software. When the software changes, people want to know why and how.
Changelogs are for humans , not machines.
There should be an entry for every single version.
The same types of changes should be grouped.
Versions and sections should be linkable.
The latest version comes first.
The release date of each version is displayed.
Mention whether you follow Semantic Versioning .
Added for new features.
Changed for changes in existing functionality.
Deprecated for soon-to-be removed features.
Removed for now removed features.
Fixed for any bug fixes.
Security in case of vulnerabilities.
Keep an Unreleased section at the top to track upcoming changes.
This serves two purposes:
People can see what changes they might expect in upcoming releases
At release time, you can move the Unreleased section changes into a new release version section.
Yes. Here are a few ways they can be less than useful.
Using commit log diffs as changelogs is a bad idea: they're full of noise. Things like merge commits, commits with obscure titles, documentation changes, etc.
The purpose of a commit is to document a step in the evolution of the source code. Some projects clean up commits, some don't.
The purpose of a changelog entry is to document the noteworthy difference, often across multiple commits, to communicate them clearly to end users.
When people upgrade from one version to another, it should be painfully clear when something will break. It should be possible to upgrade to a version that lists deprecations, remove what's deprecated, then upgrade to the version where the deprecations become removals.
If you do nothing else, list deprecations, removals, and any breaking changes in your changelog.
Regional date formats vary throughout the world and it's often difficult to find a human-friendly date format that feels intuitive to everyone. The advantage of dates formatted like 2017-07-17 is that they follow the order of largest to smallest units: year, month, and day. This format also doesn't overlap in ambiguous ways with other date formats, unlike some regional formats that switch the position of month and day numbers. These reasons, and the fact this date format is an ISO standard , are why it is the recommended date format for changelog entries.
A changelog which only mentions some of the changes can be as dangerous as not having a changelog. While many of the changes may not be relevant - for instance, removing a single whitespace may not need to be recorded in all instances - any important changes should be mentioned in the changelog. By inconsistently applying changes, your users may mistakenly think that the changelog is the single source of truth. It ought to be. With great power comes great responsibility - having a good changelog means having a consistently updated changelog. There’s more. Help me collect these antipatterns by opening an issue or a pull request.
Not really. There's the GNU changelog style guide , or the two-paragraph-long GNU NEWS file "guideline". Both are inadequate or insufficient.
This project aims to be a better changelog convention. It comes from observing good practices in the open source community and gathering them.
Healthy criticism, discussion and suggestions for improvements are welcome.
Call it CHANGELOG.md . Some projects use HISTORY , NEWS or RELEASES .
While it's easy to think that the name of your changelog file doesn't matter that much, why make it harder for your end users to consistently find notable changes?
It's a great initiative. Releases can be used to turn simple git tags (for example a tag named v1.0.0 ) into rich release notes by manually adding release notes or it can pull annotated git tag messages and turn them into notes.
GitHub Releases create a non-portable changelog that can only be displayed to users within the context of GitHub. It's possible to make them look very much like the Keep a Changelog format, but it tends to be a bit more involved.
The current version of GitHub releases is also arguably not very discoverable by end-users, unlike the typical uppercase files ( README , CONTRIBUTING , etc.). Another minor issue is that the interface doesn't currently offer links to commit logs between each release.
It’s difficult, because people follow wildly different formats and file names.
Vandamme is a Ruby gem created by the Gemnasium team and which parses many (but not all) open source project changelogs.
Yanked releases are versions that had to be pulled because of a serious bug or security issue. Often these versions don't even appear in change logs. They should. This is how you should display them:
Code formatting to improve pub scores
### Fixed - Readme improvements
[0.2.10]: https://github.com/f3ath/cider/compare/0.2.9...0.2.10 [0.2.9]: https://github.com/f3ath/cider/compare/0.2.8...0.2.9 [0.2.8]: https://github.
Your coding agent can read these notes before it upgrades. Set up the MCP server →