The changelog generator has a problem with the current release workflow.
* f18ea549 (HEAD -> master, tag: v0.31.0, origin/master, origin/maint, origin/HEAD) fix(execute): copy the table when a table is used multiple times (#1301)
* 979cf176 refactor: change the table interface (#1300)
* 3c742a58 (refactor/sql) test(stdlib): skip tests while filter produces empty tables
* 025e7f63 test(stdlib):chronograf aggregate window flux tests
* 4c61c181 test(influxdb/v1): chronograf meta query flux tests
* 3204dd2d ci: add codecov.io support to flux (#1273)
* f0b68507 Merge branch 'maint'
|\
| * ec371174 (tag: v0.30.0) feat(universe): support for dynamic queries (#1284)
* | 2cce6fe4 feat(universe): support for dynamic queries (#1284)
|/
• 32fb2fb7 (tag: v0.29.0) fix(execute): properly use RefCount to reference count tables (#1216)
The changelog currently defaults to using a depth first search when processing log entries. This works fine for a continuous chain, but in the above, it checked the entire history before finally checking the second branch.
This means that it generates the wrong changelog. But the solution is a bit more complicated than that as seen by the above. If a breadth-first search was used, it could still find changes that are unrelated. If the parents had been reversed, then the change 2cce6fe4 would have potentially been missed since the version 0.30.0 branch would have been checked first and iteration would have been finished.
It seems to me like we need to have the changelog generator walk parents and finish at either the common parent between the previous revision and the current one and have it finish at the previous revision in order to get all new commits.
The changelog generator has a problem with the current release workflow.
The changelog currently defaults to using a depth first search when processing log entries. This works fine for a continuous chain, but in the above, it checked the entire history before finally checking the second branch.
This means that it generates the wrong changelog. But the solution is a bit more complicated than that as seen by the above. If a breadth-first search was used, it could still find changes that are unrelated. If the parents had been reversed, then the change
2cce6fe4would have potentially been missed since the version 0.30.0 branch would have been checked first and iteration would have been finished.It seems to me like we need to have the changelog generator walk parents and finish at either the common parent between the previous revision and the current one and have it finish at the previous revision in order to get all new commits.