www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Changelog entries as folder or in wiki

reply Seb <seb wilzba.ch> writes:
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
Apr 20 2016
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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).
Apr 20 2016
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Apr 21 2016
prev sibling parent Seb <seb wilzba.ch> writes:
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 :)
Apr 21 2016
prev sibling parent ag0aep6g <anonymous example.com> writes:
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.
Apr 26 2016