Support tracking of GitHub releases

[DominicRoyStang]

Often times, an issue will be closed, but changes will only be actionable once they are included in the next release.
The idea is that we could treat releases as an "issue source". It is more complicated because we will need to find a reliable way to wait for the "next" release (or a specific release).

This enhancement is still in the design/ideation phase.

---

Idea 1: url to release page
A good solution would be to allow lists of issues/releases within one comment.

eg. // BlockedTODO: https://github.com/SergioBenitez/Rocket/issues/19, https://github.com/SergioBenitez/Rocket/releases

That way, we could treat it as an ordered list. ie.

1. Check if the issue is closed.
2. If the issue is still open, stop. If the issue is closed, get timestamp of when it was closed.
3. Check if there was a new release since the issue was closed.

Idea 2: releaseSource:SemVer

As simple as the above solution is, I don't really love the syntax. A big appeal of BlockedTODO is that it encourages developers to write clean comments that describe why the code is written in a particular way. A url to the repo's release page doesn't really give more context to the person reading the comment.

Ideally, I would want something more like:

• // BlockedTODO: https://github.com/SergioBenitez/Rocket/issues/19, githubRelease <-- this would notify when a GitHub release is created on the issue's repository after the issue is closed.
• // BlockedTODO: https://github.com/SergioBenitez/Rocket/issues/19, npmRelease:^0.5.0 <-- this would notify when a npm release (on a package that links to this repo) with version greater than 0.5.0 (following semver) is created after the issue is closed.

Once I add this, I will start adding examples of this as a "pro tip" at the bottom of every created task because it may not be the most discoverable feature, but it is very useful!

Some concerns with this:

• What happens when I add other issue sources (eg. Jira)?
• What if the issue is on a different repo than the newRelease repo?

Idea 3: GitHub milestones
This is a simpler solution: allow people to watch GitHub milestones, so the comment would be something like

// BlockedTODO: https://github.com/SergioBenitez/Rocket/milestone/8 switch to stable rust once this milestone is closed.

The benefits of this solution is that this is as easy as referencing an issue so I don't complicate the comment structure. A nice thing is that I could implement this in combination with other solutions. I'll probably make a separate task for this one since it's simple enough conceptually.

The only downside is that a milestone closure doesn't necessarily equal to a new release, although it has been the case for all repos I have seen thus far. If this feature were available, I would have to reconsider demand for release tracking since milestone tracking may be sufficient for 99% of use cases.