Hi all,

I had to rebase a couple of PRs lately due to conflicts with the changelog and I believe I am not the only one, which is why probably people mostly don't include their change(s) in the log anymore. AFAICT they either submit a follow-up PR once it gets merged or sometimes forget to update the changelog at all.

It would be great if we had a better, painless way to handle the changelog - two simple ideas:

1) Use a changelog folder instead of file
2) Let the users put their changes into the wiki

Honestly I prefer 1) - the changelog entry can be approved & checked during the code review on Github and the reviewers can check that such an addition is provided in the PR. On a new release we can just cat the files and remove them - having a short and long description is easy too: `mychange.short.dd` and `mychange.long.dd`. One can simply `cat *.short.dd  *.long.dd` to get the full changelog. Btw grouping of similar changes is automatically done by the filenames.

Cheers,

Seb

On Wednesday, 20 April 2016 at 23:51:41 UTC, Seb wrote:
> Honestly I prefer 1) - the changelog entry can be approved & checked during the code review on Github and the reviewers can check that such an addition is provided in the PR. On a new release we can just cat the files and remove them - having a short and long description is easy too: `mychange.short.dd` and `mychange.long.dd`. One can simply `cat *.short.dd  *.long.dd` to get the full changelog. Btw grouping of similar changes is automatically done by the filenames.

Agreed.

Previewing the changelogs in the doc tester would be nice too (on my list).

On 4/20/16 11:09 PM, Vladimir Panteleev wrote:
> On Wednesday, 20 April 2016 at 23:51:41 UTC, Seb wrote:
>> Honestly I prefer 1) - the changelog entry can be approved & checked
>> during the code review on Github and the reviewers can check that such
>> an addition is provided in the PR. On a new release we can just cat
>> the files and remove them - having a short and long description is
>> easy too: `mychange.short.dd` and `mychange.long.dd`. One can simply
>> `cat *.short.dd  *.long.dd` to get the full changelog. Btw grouping of
>> similar changes is automatically done by the filenames.

Yes. It's not entirely clear how to add things to the changelog, and conflicts are easy to create.

I will note that any time a PR fixes an issue (and the issue is simply a bug), there is no need for a changelog entry, as Martin auto-generates a list of all the bugs fixed. It's those complicated changes, or ones that have no issue that need an entry.

> Agreed.
>
> Previewing the changelogs in the doc tester would be nice too (on my list).

+1, I have no idea how changelog entries look because I have no idea what the macros do :)

Making it easy to auto-generate the changelog from these files would be useful for release time as well.

-Steve

On Thursday, 21 April 2016 at 03:09:43 UTC, Vladimir Panteleev wrote:
> On Wednesday, 20 April 2016 at 23:51:41 UTC, Seb wrote:
>> Honestly I prefer 1) - the changelog entry can be approved & checked during the code review on Github and the reviewers can check that such an addition is provided in the PR. On a new release we can just cat the files and remove them - having a short and long description is easy too: `mychange.short.dd` and `mychange.long.dd`. One can simply `cat *.short.dd  *.long.dd` to get the full changelog. Btw grouping of similar changes is automatically done by the filenames.
>
> Agreed.
>

I opened a PR for this - https://github.com/dlang/phobos/pull/4228/files :)

On 21.04.2016 01:51, Seb wrote:
> It would be great if we had a better, painless way to handle the
> changelog - two simple ideas:
>
> 1) Use a changelog folder instead of file

After having rebased a pull request for the third time just because of changelog.dd: Sounds good to me.