Changelog in the documentation

[razvanz]

You should add a changelog in the readme file (even on the release description).

Updating to 4.1.0 from 4.0.6 made my project throw errors and I had to dive in the module code in order to fix it. I would prefer (I assume others as well) find the solution for things that break compatibility in the documentation.

PS: Be careful with versioning! A minor update should not break the system. Show a warning or something. As they say in the Semantic Versioning:

MINOR version when you add functionality in a backwards-compatible manner

[isaacs]

This project's goal is to match the behavior of Bash 4.3. Any changes that bring it closer to the matching semantics of Bash 4.3 are considered bugfixes and bump the patch version.

Opt-in features that provide alternative behavior are considered additive changes, and bump the minor version. Minor versions may also include bugfixes.

Removal of opt-in features, or changes to the API surface, are considered breaking changes, and bump the major version. Major versions may also include bugfixes and additive changes.

If you are a depending on a bug, then a bugfix will break your system.

I'm happy to include a changelog, but I'd rather use a tool to generate it manually, as this is quite tedious. Do you have any recommendations?

[ilanbiala]

A changelog would be great. @isaacs do you mean a tool to generate it automatically? I know that some open-source projects use an automated changelog creator, but their commits are phrased a certain way like with AngularJS.

[glen-84]

The changelog is outdated.

[razvanz]

I guess this is no longer relevant; for a while now!