Add change log file.

[skywinder]

Hi, as I can see, you are carefully fill tags and labels for issues in your repo.

For such cases I create a github_changelog_generator, that generate change log file based on tags, issues and merged pull requests from Issue Tracker.

This PR add change log file to your repo (generated by this script).
You can check, how it is look like here: Change Log

Some essential features, that has this script:

• it exclude not-related to changelog issues (any issue, that has label question duplicate invalid wontfix )
• Distinguish issues according labels:
  • Merged pull requests (all merged pull-requests)
  • Bug fixes (by label bug in issue)
  • Enhancements (by label enhancement in issue)
  • Issues (closed issues w/o any labels)
• Generate neat Change Log file according basic change log guidelines.

You can easily update this file in future by simply run script: github_changelog_generator appsquickly/Typhoon in your repo folder and it make your Change Log file up-to-date again!

Hope you find this commit as useful. 😉

[skywinder]

Since you don't use question duplicate invalid wontfix labels in your repo - you can exclude any issues without labels (github_changelog_generator --no-issues-wo-labels), then change log will contain only issues with labels bug and enhancement + merged pull requests.

[alexgarbarev]

Hey @skywinder, That tool looks very nice, I like to automate boring tasks like that. But I notice strange bug in generated changelog:
AppDelegate auto-injected properties not injected #342 was fixed in 3.1.6 but in generated changelog it placed under 3.1.7

[skywinder]

@alexgarbarev Since #342 closed 19 days ago (2nd of may) and tag 3.1.6 is placed 1st of may - generator assumes, that it was closed after release.

That is a known case (look at github-changelog-generator/github-changelog-generator#22 for more details).
And know there is workaround accomplished by this feature:

Ability to manually specify in which version issue was fixed (in case, when closed date is not match) by setting milestone of issue the same name as tag of required version 📌

That is the easies an more convenient way, that I fugired out. If you have other ideas, how is better to handle such situation - let me know!

So, just set milestone for this issue 3.1.6 and this issue moves to correct version with next change log generation.

[jasperblues]

Let's merge in and fix up issues with the change log. While we generally push value adding features as a micro-version as soon as they're available, users have been asking for a more formal tracking. Given that Typhoon is a self funded open source project it adds some overheads, so we really appreciate being able to automate.

[alexgarbarev]

@skywinder Ah.. Got it! Thanks for explanation! I didn't notice that before!

[alexgarbarev]

@skywinder Just checked again.. Can't understand what wrong here:

Tag 3.1.6
commit 10d90c5
Author: Aleksey Garbarev
Date: Sat May 2 02:51:39 2015 +0600

Commit "Fixed bug #342"
commit 10d90c5
Author: Aleksey Garbarev
Date: Sat May 2 02:51:39 2015 +0600
Message: Fixed bug #342

So.. Looks like tag cannot be set earlier than this bugfix commit, because 3.1.6 tag points to that commit

[alexgarbarev]

Hey,

Just now I pushed new release 3.1.8 which introduce fix for next issue: #352
But when I updated changelog by running: github_changelog_generator appsquickly/Typhoon I have changelog which missed my fix from above.
Here is the result: https://github.com/appsquickly/Typhoon/blob/master/CHANGELOG.md

@skywinder, Can you help me to understand what I'm doing wrong?

[skywinder]

@alexgarbarev ok, let me check it tomorrow! I will handle it! 😉

[jasperblues]

The 'pod' badge in the readme links to the old (poorly maintained) changelog. Once ready we can link to the new one.

[skywinder]

@alexgarbarev with #352 & 3.1.8 - it's definitely that case, that I describe above.

Tag 3.1.8
CommitDate: Thu May 21 23:18:52 2015 +0600

And issue closed (according github popup message) at 23:45 (GMT +6)

[jasperblues]

Makes sense. Sometimes I have had to push a new release while some tickets are still marked as 'Ready for Review' . . . we'll have to avoid this in future.

[skywinder]

@alexgarbarev Gotcha!

You create reference to the issue with commit, But it don't close commit (because of formatting of commit message - "Fixed bug #342". It should be smth like "Fixed #342" to make it close the issue.) And then you close this issue manually later, that tag was placed already!

at 2nd of May 0:50 GMT +3

And tag date is 1st of May 23:51 GMT +3

That's why it's not in this section.

[alexgarbarev]

Ah.. Right, thanks for explanation. I didn't know that

[skywinder]

@alexgarbarev Ok, but there is another bug (or feature ❓ ). As you mention - there is no #352 at all! Even if it closed later - it should appear in Unreleased section.
But it doesn't. Look at github-changelog-generator/github-changelog-generator#240 for details.

If you have ideas, how better to handle such cases - I will be glad discuss it!