move changelog to a folder

[wilzbach]

As discussed at the newsgroup I think it would be more painless if we put the pending changes into a folder, s.t. that no merge conflicts arise anymore.

• I also found that we can eliminate one main error source - the $(LI ) ddoc macro and make it even easier to add entries as one entry is always one item
• For cross-platform compatibility (and maybe further improvements) I included a small script that builds the changelog from all pending entries.
• I added small README that should provides instructions to contributors
• I use a p_ prefix, s.t. removing the pending entries is easier, but this is not required.
• I copied all pending entries into the new format

I am happy to hear your feedback.
Pinging @CyberShadow @schveiguy @MartinNowak

[CyberShadow]

Oh wow, so these changelog files are referenced after all. Looks like build_changelog will need an update. Perhaps it should support both the old and new format (at least at first) so we don't do a risky "merge everything at once".

[wilzbach]

Oh wow, so these changelog files are referenced after all. Looks like build_changelog will need an update.

sorry to ask, but what do you mean by that?

[CyberShadow]

Look at the log of the failed doc build :)

Edit: Yeah I did misinterpret it, fail at reading the PR description, and jumped to conclusions. Still, it's failing.

[wilzbach]

Edit: Yeah I did misinterpret it, fail at reading the PR description, and jumped to conclusions. Still, it's failing.

The problem is that it contains a main method and thus is run for dmd -c -o- -version=CoreDdoc -version=StdDdoc ... - I added a quick version statement to avoid that. Is there sth. like version(!CoreDdoc)?

[CyberShadow]

version(CoreDdoc){}else:

[CyberShadow]

Now we just need to get the output into the dlang.org prerelease changelog :)

[CyberShadow]

BTW, perhaps the tool should reside outside of the Phobos directory so it could also be used for the compiler and Druntime.

[CyberShadow]

Here's the existing script that I got confused over:
https://github.com/dlang/tools/blob/master/changed.d

[wilzbach]

BTW, perhaps the tool should reside outside of the Phobos directory so it could also be used for the compiler and Druntime.

How about dlang.org or tools?

Now we just need to get the output into the dlang.org prerelease changelog :)

This probably means adding it to the dlang.org Makefile?

[wilzbach]

Here's the existing script that I got confused over:
https://github.com/dlang/tools/blob/master/changed.d

Maybe we can even combine both scripts when we render the prerelease changelog?

[CyberShadow]

This probably means adding it to the dlang.org Makefile?

Yep. We'd need to 1) run it 2) copy the result under web/ so it gets exported, and can be previewed on the autotester.

Ideally it would build a pre-release changelog for the next version, so it's visible and discoverable on dlang.org, but that may be more involved.

[wilzbach]

@CyberShadow I removed the build script from this PR and will create a PR soon for the tools repo and dlang.org repo. This means this PR is complete from my side now ;-)

[wilzbach]

I forgot to ask: anyone out there who objects this change?
You shall either speak now or forever hold your peace ;-)

[aG0aep6G]

The version number is going to be forgotten here. Maybe just go with "next release".

[JackStouffer]

I'm getting really tired of rebasing due to changelog diffs.

Let's move forward on this ASAP. LGTM

[wilzbach]

I'm getting really tired of rebasing due to changelog diffs.
Let's move forward on this ASAP. LGTM

I have rebased this PR to the latest changes. Also I realized these things

1. Having only one file is move convenient (and we now will run the DScript anyways) -> we can automatically generate the linking and link names
2. Title shouldn't contain links
3. In most cases it's better to have short title and a good description. We should enforce in the future that (at least) additions get a proper one
4. Having an own, simple format allows us to add custom properties in the future (e.g. category, break, affects, ...)

So the only question left is what (simple) file format we are going to use?
My proposal looks like this (should be easy to parse), but of course I am happy to other suggestions (yaml, ini, sdl, ...).

Title: Breaking change
Description:
This change will break everything

Obviously the generator tool has to be updated to the changes here, but I argue that can also be done after this PR is merged, so that we don't have to rebase too often and people can start writing their changes in the new format.

[AndrejMitrovic]

I like the idea a lot (conflicts are a pain), but the changelog typically splits up the changes to compiler / language / library sections (see http://dlang.org/changelog/2.071.0.html). How will this work with the new system?

Edit: Nevermind I was in the wrong repo.

[AndrejMitrovic]

Woops, this is phobos not dlang.org. Please disregard my previous point.

[wilzbach]

Woops, this is phobos not dlang.org. Please disregard my previous point.

FYI: At Dconf16 we agreed that splitting this up makes sense, but wanted to wait for the next release.
Once 2.072 gets branched off, I will rebase this PR, make appropriate PRs to dmd and druntime and make the concatenation tool better (PR is already pending at the tools repo).

[wilzbach]

Okay now that 2.072 is merged, we can finally move on with this 🎉

For now I just added the README file that describes the discussed Git commit-like format (title, separator line,description paragraph). The tool that parses the changelog files is dlang/tools#186 and will hopefully be finished soon (this weekend). Once it's finished, we should be able to add a proper Makefile target, go ahead and finally pull the trigger here.
However if someone already has a PR with a changelog entry coming up / in work, we could also move on directly (and create the initial changelog directory).

[wilzbach]

Rebased with the latest changelog.
FWIW there was only one entry in the changelog and even this one was broken, so maybe we can make the move to the by far simpler format this time ;-)

[wilzbach]

(rebased)