Thanks @khellang.

I removed it from the 0.14 milestone since it doesn't affect the release in anyway. It's purely an enhancement to building from source on *nix.

OK, but isn't it still part of 0.14 (in time)? I'm used to assigning all merged PRs to the upcoming milestone, so it's easy to see what's been merged in which version.

It's a fair point. I guess can it can be viewed both ways.

To be honest, I kind of made up the milestone policy myself when I was curating the closed issues for the big 0.10 release (if which there were many) and I just found it easier to only assign issues to the milestone which actually affected the release. For that reason I generally excluded anything like build issues (although looking back it now that's not strictly true).

Aside from that, there is the whole PR vs issue thing, i.e. when a PR closes an issue do we do labelling and milestone assignment on both, or just one, and which one? Should we enforce that an issue is always raised for every functional change and a PR is simply a thing that closes one or more issues? (We do that in some other projects and it works well.)

We probably just need to agree our approach and put it on the wiki, e.g. https://github.com/FakeItEasy/FakeItEasy/wiki/Managing-pull-requests