It would be nice to be able to interact with a CHANGELOG.md when not in the same directory as the file (for example, if you are a sub-directory, etc).

Ideas:

• Accept --path argument to CHANGELOG.md location.
• Accept $CHANGELOG=/path/to environment variable.
• Traverse the chain of parent directories to identify a CHANGELOG.md file.

it would just return the last line of each section.
This worked fine, since nothing else in the code was actually reading the contents, just the existence of a section.

IMO, we could:

• Change it to return all changes, as I have done in #22
• Change it to get_unreleased_change_types and just returned the change types, as I have done in #24

I have a preference for the latter, since the code gets simpler.

Aside: I noticed this while adding the typing information in #21

travis-ci.org is shutting down soon, and has stopped doing builds for mc706/changelog-cli.

We have to migrate to a different system.

While we could migrate to the new travis-ci.com (which is configured using GitHub Actions), I would prefer to migrate to something else:

In order of preference

1. GitHub Actions itself
2. CircleCI
3. TravisCI

I have experience with GitHub Actions and CircleCI for other projects.

• Here is an example of a simple build I use GitHub Actions for.
• Here is an example of a more complicated project that I use CircleCI for. I would use GitHub Actions for this too, but it will soon be a much more complicated build (once I add binary wheels; but that's another story)

It would be handy to have an option to tack a git commit command along with the cl command, using the same message.

For example, right now you might manually do the following:

changelog new "add new feature x"
git commit -m "add new feature x"

With an optional flag, you could do both with one command:

changelog --git added "add new feature x"

I love the spirit of this tool, but it's a bit disconcerting that pypi currently has version 0.7.1, but this repo is at 0.7.0. Oddly, pypi has no history of 0.7.0, and just as oddly, github has no history with 0.7.1.

Can we get a new release to pypi to clear this up? I especially like the added|changed|deprecated|removed|fixed|security format over the old new|change|fix|breaks

First minor release is 0.2.0, which is a bit weird as a first entry. change to 0.1.0

changelog-cli tries to determine the appropriate next version number for the project. But the changelog is never (?) the only place in the repo that stores the version number.

There's often a VERSION or a _version.py, setup.py etc. file that actually stores the machine-readable version number.

changelog-cli could be configured to update these locations at the same time, so all the copies of the version number stay consistent.

How could it work?

We could have a .changelog-cli config file in the root of the repo.
Inside, we could have a mapping of filepaths to regexes.

Each filepath would be a file that contains a version that needs updating, and the regex would tell changelog-cli where to find the version number within the filepath. Something like:

[Version Files]
src/changelog/_version.py: '__version__\s*=\s*(\S*)'
setup.py: 'version=(\S*)'

In this example (using Python's configparser format) changelog-cli release would not only modify the CHANGELOG, but also src/changelog/_version.py and setup.py. In each, it would use the regex to find the version. The contents of the "group 1" of each match would be replaced with the new version number.

The exact file format of the .changelog-cli file could be something that Python supports in the standard library (json or configparser), so there would be no additional dependencies needed and we wouldn't need to implement a new parser.

Another nice benefit of having a config file would be having a place to include other settings, like one for controlling the creation of a table of contents within the CHANGELOG (#14) (Although there are probably easier ways to do that).

Given that this is a command line tool and not a library, perhaps we can keep pace with the currently supported versions of Python instead of all the versions?

Not only would we be able to make use of more modern syntax and features of the language, but we wouldn't have failures like our recent failures in TravisCI where a development dependency has dropped support for those versions.

cc @mc706

Some projects have a table of contents at the top of their CHANGELOGs.

This allows readers to quickly jump to the version they are interested in.

Add some mechanism to request that changelog-cli autogenerate a table of contents?

We should properly license changelog-cli.

@mc706 Any complaints with MIT?

On a existing project, have changelog init check if the ## Unreleased section is available in the changelog to ensure that it works.

Add gif of usage

Hello,
this is great tool and until recently I've got no trouble using it.
But this line:

Keep a changelog has more types of section headers. Support them

Have Version Types be consistent with existing project

Pylint 2.10 added a linter that checks for open calls that don't explicitly specify an encoding.

Ref: pylint-dev/pylint#3826

Since we have not pinned the version of Pylint used in the CI, the build pipeline is failing.

Potential solution

• Fix the violations (PR here)

It seems that using the --yes flag with release causes the recommended release type to be used rather than one specified by the command. See examples below.

It looks like a simple fix - will hopefully raise a PR as soon as I can get my head around how the tests work!

$ changelog suggest
0.7.1

$ changelog release --patch
Planning on releasing version 0.7.1. Proceed? [y/N]: N

$ changelog release --minor
Planning on releasing version 0.8.0. Proceed? [y/N]: N

$ changelog release --major
Planning on releasing version 1.0.0. Proceed? [y/N]: N

$ changelog release --major --yes

$ changelog current
0.7.1

I think it would be useful to allow changelog-cli to create a new git tag when running changelog release, with the version's changelog as the tag's message.

I might do a PR to add this, is there any preference on using the git command line tool directly or a library like gitPython?

Sometimes we might need to process changelog into another format.
For example I might want to get existing changelog file and transform it to debian changelog ( https://manpages.debian.org/jessie/devscripts/dch.1.en.html ).

To do that it would be convenient to have intermediate machine readable format, like for example JSON, to which current text in changelog could be processed to and which could be used then by custom script or template engine to produce a different format of changelog.
For example command might look like this changelog export --format json

I installed this helpful looking project va pip, but how do I actually invoke it in the way shown in your readmes?

changelog is not a program on my computers path, and that's not valid python syntax, so how are you running it exactly?

If you add a section header that is not there, create it first

Ref: #21 (comment)

Hello folks, firts at all thanks for developing this tool,

I'm using it, but I see last release was on Feb 2020,

Accoding to https://github.com/anton-yurchenko/git-release and https://keepachangelog.com/en/1.1.0/ changelog-cli does not comply with the chagelog nomenclature.

Is it possible to have that update? if so, do you have any planned release?