Unexpected behavior of release note generation between tags

[dahluwalia-ag]

Great tool and appreciate that you wrote this. I am trying it out and have run into an unexpected behavior.

This is probably best explained in an image, so please see the below image.

Basically, the issue is that I expecting that release notes pick up commit messages between tags in the following way:

• tag 2.0.0 (another commit msg here "close issue 3")
• commit msg 1 "close issue 2"
• commit msg 2
• tag 1.0.0 ( a commit msg here: "close issue 1)

For release version 2.0.0, I expect to see: "close issue 3" "close issue 2" "commit msg 2"

My testing repository is here: https://github.com/Aperio-Group/testingstuff/settings

Here were my commands I used: 2061 git push origin v3.0.0 2062 gren release 2063 git touch adding_feature.txt 2064 touch adding_feature.txt 2065 git add adding_feature.txt 2066 git commit -m "adding a cool feature. this closes #7" 2067 touch adding_another_feature.txt 2068 git add adding_another_feature.txt 2069 git commit -m "adding another feature. this closes #8" 2070 git tag v3.0.1 2072 git push origin v3.0.1 2073 gren release

Please let me know if I'm using the tool incorrectly.

[alexcanessa]

Hello @dahluwalia-ag

I’ll investigate and see what I can do :)

[alexcanessa]

@dahluwalia-ag we couldn't find any errors in terms of issues timeline generator.

I've noticed that few issues (7 and 8) aren't closed.

To make sure that everything is clear, have a read of how issue tracking works.

As explained in that paragraph, to be more specific about which issues a release should contain, you can use Milestones.

I really hope this solves your problem. Let me know so that I can update this issue.

[dahluwalia-ag]

Thanks for the feedback! Yes, you're right, those github issues are still open. Something is wrong with my testing repository because some commits didn't get pushed. I'll test again and report back if anything is still fishy. (So far looks like my user error!)

[dahluwalia-ag]

So I had a chance to play around with the tool today.

I now understand what is going on. As you mentioned, gren is using the "date the issue was closed". I am driving the closure of issues through my commit messages. However, the date the issues actually get closed is when the commits are pushed. This was the cause of the disconnect. I thought the "issue closure date" was the same as when I "closed" the issue in the commit message.

I like the idea of using the "issue closure date" because one can close issues manually (via the web interface), and they should show up in the release notes.

However, I also plan to close issues with commit messages because then github nicely links the issue with the changeset. The tool might work as-is if I am careful about the timing of the pushes and tagging. (My testing is a worst case scenario--things are likely to happen much slower in the real use of the tool.)

I changed the data-source to the commit messages and I'm getting closer to what I want. However, I don't really want to generate release notes based on all commit messages. I just want to include messages which have closed an issue. Is it possible to add a regex for filtering against commit messages (e.g. ones that look like they reference closing an issue).

Another nice feature would be a detect-issues-in-commits flag which uses data-source commits and the issue-finding regex, then only links to issues, not commits. Could also combine any "manually" closed issues (data-source=issues) to make sure all truly closed issues are captured.

Maybe I will take a stab at adding these functionalities in the near future.

[alexcanessa]

Hello @dahluwalia-ag,

It makes sense that the issue gets only closed when the commit gets pushed, but I totally see your point.

Currently, we have an option to ignore commit messages that contain specific words (see documentation here), I really like your idea of an option to operate the other way around.

In the meantime, could I suggest to use Milestone to define your releases, so that you can still use issues and have more control over what gets included in a release.

See more details here