Non-linear release histories not supported #497
Labels
Comments
|
Totally 👍 for this. Maybe also related to #256 Supporting two or more branches is common, bugfixes go to the lowest supported branch and then merged in more recent branches, while latest branch keeps getting PR merged in the meantime. This bug mixes the result that therefore must be manually cleared 😞 |
|
#619 fixes this for PR merge detection but doesn't fix it for the generated diff links. Something like #619 (comment) would be needed. |
This was referenced May 26, 2019
|
It is unclear to me what the desired result is. Should new changes in the 0.2.x series even appear in the 0.3.x changelog? If not, the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I may have missed a flag or something, but this doesn't appear to support release histories that include multiple maintained release branches.
As an example, see the changelog generated for github.com/pilosa/pilosa: https://gist.github.com/codysoyland/703101d5be09fc811cb3f7a6ab8d1e8e
As you can see, we made releases in the following order:
However, the changelog assumes that each of these releases was an evolution from the previous by order of date. But we are actually maintaining two release branches, a 0.2.x branch and a 0.3.x branch.
In other words, the previous version that is used to generate the change list and diff link should not be the previous tag by date, but the most recent tagged ancestor in git history.
The text was updated successfully, but these errors were encountered: