next-gen changelog generation

[TomasTomecek]

I propose release bot generates change log like this:

• It lists all PRs which landed to a release.
• It generates the list in following syntax:

* [<pull request title>](<link to the PR>), thanks to @<PR author>
  <PR description>
  * <commit message>
  * <commit message>

• This is put into changelog.md for maintainer's review.

Everyone has good ideas how this could work: when you start working on this please be ready for a lot of feedback.

Edit: this is a very good candidate for Google Summer of {Docs,Code} or Red Hat Open Source Contest.

[lachmanfrantisek]

What about using gitchangelog?

By default it needs the commit prefixes to distinguish fix/new/change, but we can set custom regex for this (e.g. [fix]/[chg]/.. in the commit message).

The markdown output looks good to me. (if output_engine = mustache("markdown"))

[TomasTomecek]

looks good, definitely worth of trying out: we don't need to implement this ourselves

[shresthagrawal]

@TomasTomecek I am working on it :+1:

[shresthagrawal]

If I understood the proposal properly: Once a release is triggered, the Bot should get the list of PRs and add them in the above given format. But the current method does the same thing for commits just it doesn't add the PR title and details? So I just need to add the PR details ? do I need to update the CHANGELOG.md file also ? And what about the changes/commits done without a pull request?Thanks

[rpitonak]

@shresthagrawal yes, you need to add titles of all PRs created since the last release.

And what about the changes/commits done without a pull request?

We don't push any code directly to the master branch, so you don't need to care about this scenario.

[TomasTomecek]

But on the other hand, some other users of release bot may do that. So for commits done without PRs, I would do the same thing as the bot does now.

@shresthagrawal did you also look into the gitchangelog project whether it would be useful here?

[shresthagrawal]

@TomasTomecek I think so gitchangelog would be a perfect fit for the concept! Working on how we should integrate with the current code.

[lachmanfrantisek]

@TomasTomecek I think so gitchangelog would be a perfect fit for the concept! Working on how we should integrate with the current code.

I like the gitchangelog as well. We will probably need to:

1. tag new version
2. generate changelog
3. remove tag (Or not push the tag.)

Some years ago, I've done a similar thing. And also working with gitchangelog from code was a pain.

[shresthagrawal]

@lachmanfrantisek Sorry I didn't got the concept of tags(1. and 3.) can you please elaborate.

[lachmanfrantisek]

@lachmanfrantisek Sorry I didn't got the concept of tags(1. and 3.) can you please elaborate.

As I remember:

• Gichangelog generates the changelog from commit messages, that are prefixed (fix: something, add: other).
• Changelog for one version is generated from the commits between two git tags, that points to the releases.
• We want to add changelog for the new version to the CHANGELOG.md file and then commit these changes in the PR. After the merge, we need to create a tag and GitHub release. (But we need to have a temporary tag with the new version for the generating changelog that needs to be there before the release... Egg and the Chicken problem..;-) We just need to be careful to not push the temporary tag to the repo.)

---

Gitchangelog has a config file, that can tweak the output-format, commit-prefixes,...

[lachmanfrantisek]

Changelog for one version is generated from the commits between two git tags, that points to the releases.

Maybe a second approach: The gitchangelog generates the changelog for the non-released code as well, but we probably need to tweak the output a bit.

[shresthagrawal]

@lachmanfrantisek I think using the unreleased changelog would be a good choice to go with! Is their a way to generate only a part of the changelog or else do we need to generate the complete changelog everytime. What I think would be a good approch would be to get the content of just the unreleased block and update our already existing changlog file and leave rest of the process the same.

[lachmanfrantisek]

Is their a way to generate only a part of the changelog or else do we need to generate the complete changelog everytime

I think you can specify the commits with e.g. 0.1.0..HEAD. (Old version to head.)

What I think would be a good approch would be to get the content of just the unreleased block and update our already existing changlog file and leave rest of the process the same.

:+1:

[shresthagrawal]

@lachmanfrantisek What do you think of the gitlogconfig file ? should we have it all configured on our side or give the user acccess to it ? or should we have a check if the user has provided his own config and if not just use one of the default script.

[lachmanfrantisek]

or should we have a check if the user has provided his own config and if not just use one of the default script.

Yes, we need a good default, without any work from the developer side.

But, if someone wants to tweak it, then we have to allow them to do it.

[shresthagrawal]

@TomasTomecek @lachmanfrantisek I thing, It would be really good if we have a feature like release-bot init which adds all the config files(conf.yaml and release-conf.yam) to the current repo. it would be just a shell script which asks some basic questions and does all the initialization ? that would also ask if the user wants to gitreleaselog if yes then it automatically adds a default config for gitreleaselog also?

[shresthagrawal]

I think you can specify the commits with e.g. 0.1.0..HEAD. (Old version to head.)

Thanks gitchangelog ^<latest_release_version> HEAD would return only the unreleased logs

[TomasTomecek]

release-bot init is definitely a good idea, please start a new issue for that and let's not complicate this one