@matkoniecz the PR appears in the next version tag after merging, isn't it?

You can manually specify in which version PR was merged by setting milestone of PR the same name as tag of required version.

p.s.
Any ideas, how to detect, in under which tag this PR should presented?

We don't use milestones in that way, so that's not really an option.

Any ideas, how to detect, in under which tag this PR should presented?

The earliest tag where all the commits in the PR are present

@pnorman I don't think that it will be correct behaviour in most of the cases.
If PR is merged after tag is placed in general it means that this feature will appear in next release.

I generated a changelog, and gravitystorm/openstreetmap-carto#1540 appears under v2.30.0. This PR only had one commit, gravitystorm/openstreetmap-carto@89301f1

If you look at the tags this is part of on the web interface, it is only part of v2.32.0. You can verify this with git name-rev --tags 89301f1394698e6634d58092f68e156e73e7cd38 which shows it is tags/v2.32.0~6^2

@pnorman not matter, when it was committed. Because it could be long-term feature, that developer prepare for next releases. In that case determining by last commit will be incorrect.
And I can be sure for 100% that this feature in production only after merging of related branch.

git name-rev unambiguously tells you that it is part of v2.32.0

@pnorman not matter, when it was committed

I'm not sure what you're trying to say here. If you're trying to say the commit date doesn't matter, that is correct. e.g. "especially since comparing commit dates in a project’s history doesn’t necessarily correspond to the order in which they were applied" from http://mislav.uniqpath.com/2010/07/git-tips/

I've seen a similar issue when needing to push a patch for an old release; patches applied on the mainline before the patch (v0.11.1) are showing up in the changelog there instead of v0.12.0 which is where they actually got released. Sorry, this was a private repo but I can probably generate an example in a simple repository.

@Oscil8 it would be great, if you can provide some examples.
I'm using https://github.com/skywinder/changelog_test/ repo to test change log behaviour. If you can reproduce this case in this repo - it would significantly helps me to understand this issue.
I can get you access to this repo to create necessary tags, commits and issues.

@matkoniecz This error could related with #271. Please check, how it works now!

"adding antarctic icesheet rendering based on preprocessed shapefiles #1540 (imagico)" is still listed for v.2.30.0 (I updated gems).

same issue here!
I commit my changes in #78 branch and I commit a pull request against master. After that, someone label master with 3.0.4 (but #78 is still pending to merge, nobody has reviewed the pull request). After releasing the 3.0.4 someone review and merge the #78 in master. And the next time the CHANGELOG is generated, the #78 is under the 3.0.4 automagically. I don't think that this is the expected behavior, but having the #78 as part of the next release

@aparraga which repository are you talking about? let me have a look on it please

I have just tested this, and with the current release of github_changelog_generator, the pull request from openstreetmap-carto is now correctly listed under release 2.32.0.

So, this ticket can be closed.

/cc @olleolleolle