Add change log file.

[skywinder]

Hi, as I can see, you are carefully fill tags and labels for issues in your repo.

For such cases I create a github_changelog_generator, that generate change log file based on tags, issues and merged pull requests from Issue Tracker.

This PR add change log file to your repo (generated by this script).
You can check, how it is look like here: Change Log

Some essential features, that has this script:

• it exclude not-related to changelog issues (any issue, that has label question duplicate invalid wontfix )
• Distinguish issues according labels:
  • Merged pull requests (all merged pull-requests)
  • Bug fixes (by label bug in issue)
  • Enhancements (by label enhancement in issue)
  • Issues (closed issues w/o any labels)
• Generate neat Change Log file according basic change log guidelines.

You can easily update this file in future by simply run script: github_changelog_generator gphoto/libgphoto2 in your repo folder and it make your Change Log file up-to-date again!

Hope you find this commit as useful. 😉

[ndim]

Thank you for this PR!

This is not a normal PR about merging a commit or a few commits. This PR is about changing the process of generating file with changes (Changelog.md, NEWS, or whatever it may be called).

Running the github_changelog_generator utility must then happen either

• locally on a developer's machine before every git commit to update the Changelog file in sync with every commit
• locally on the developer's machine who prepares a release, before every release to update the Changelog file in sync with every release

I would not want to require every developer to have a working Ruby universe installed for whatever Ruby and Gem versions github_changelog_generator requires at the time it need to run. So this leaves only the "for every release" time to run github_changelog_generator.

At release time however, a lot of time has already passed without an update, so a lot occasions for the Changelog to have been useful are already long over. However, the generated Changelog might still be useful inside a release tarball, and in release notes on github and gphoto.org.

This would mean adding a few steps to RELEASE-HOWTO.md, and requiring that the developer preparing the release needs a working Ruby and Gem environment and github_changelog_generator installed. And if we are realistic, while I can help figuring out some scripting to partially automate the steps in the RELEASE-HOWTO.md, it will mostly affect @msmeissn, so I will not force this upon him.

IMHO, using github_changelog_generator makes a lot of sense in the following two cases:

• Packages using Ruby anyway can use it in a per-commit capacity. We do not Ruby anywhere.

• For other packages (like the gphoto packages) a Changelog HTML page like the one created by github_changelog_generator should be part of the github release and/or github web interface, or on its own website integrating with github. I might use such a website, or a part of the github web interface, but will not set up a website with such a web service.

Summarizing: For our case at the gphoto project however, I am sceptical about the cost/use ratio in terms of extra work this generates with a limited usefulness.

[skywinder]

@ndim it was

Packages using Ruby anyway can use it in a pre-commit capacity. We do not Ruby anywhere.

It's OK to run it once in a while, just to update the changelog file. You don't have to force every developer o to install it.

You can run it on the server-side as part of the CI/Cd process.