https://d.puremagic.com/issues/show_bug.cgi?id=12240
Vladimir Panteleev <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |[email protected] AssignedTo|[email protected] |[email protected] --- Comment #1 from Vladimir Panteleev <[email protected]> 2014-02-25 18:10:39 EET --- More advantages: - Using pull requests for changelog generation also frees us from the "paperwork" of filing an issue just for documenting a change. - Using a date range no longer works with the new release process. A bug fixed in "master" but not the release branch will show up on the release's changelog (and respectively be omitted in the next release's changelog). Plan: - Generate the git log between the two tags. It is trivial to extract the pull request URLs from the git log. Digger [1] does this. - Additional information can be obtained by querying GitHub using its API. Questions: - We still need a way to figure out whether a particular pull should be included in the changelog. For example: - Fixes to features added after the last release - Fixes to regressions introduced after the last release - Changes which do not affect D users, such as refactorings Although this can be done by hand at changelog generation time, that would be suboptimal and error-prone. One way to do this would be naming conventions for pull request topics, e.g. [internal]. (GitHub issue tags have the disadvantage that only repo collabs can assign them.) [1]: https://github.com/CyberShadow/Digger -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
