Wiki page
[AutoupdateGithub] by
mario
2015-03-21 01:00:35.
D 2015-03-21T01:00:35.016
L AutoupdateGithub
N text/x-markdown
P f4befd6b970882a7b6b1959d944876a2c159bae4
U mario
W 1898
For [GitHub](https://github.com/)-hosted projects there's a particular simple release [autoupdate](wiki/Autoupdate) scheme. Just provide at least one link to your github-repo (as primary Autoupdate URL, Homepage, Download or in Other URLs).
* A projects `tags.atom` will be polled daily for version number updates.
Version number prefixes like `"v"` and `projname-` prefixes will be stripped from tags. Only the `1.2.3*` style version number will be retained from tags. Release titles are generally ignored.
* `http://github.com/$user/$project/releases` is the preferred way to retrieve a changelog. The first bulleted task-list will be presumed to be individual change notes.
<img src="https://camo.githubusercontent.com/9f23f54df9e2f69047fb0f9f80b2e33c8339606f/68747470733a2f2f662e636c6f75642e6769746875622e636f6d2f6173736574732f32312f3733373136362f62643163623637652d653332392d313165322d393064312d3361656365653930373339662e6a7067" width=600 height=300>
This is what <a href="https://github.com/blog/1547-release-your-software">GitHub itself recommends for publishing releases</a>. Albeit only major projects are utilizing it, e.g. [/atom/atom](https://github.com/atom/atom/releases).
* Alternatively a `*` bulleted list from `tags.atom` `<content>` will be used.
So you can have your commit message for a tag contain a changelog-style summary.
* As fallback `$repo/compare/0.9.9...1.0.0` will be used for condensing commit logs into a summary.
This is obviously not often a user-friendly changelog. Therefore it's rate limited. Which might incur delayed bugfix release announcements.
For projects where this fallback repeatedly only generates developer/commit changelogs, it'll probably be moderated and disabled.
Some basic filtering (removing "merged pull request xyz" entries) is applied.
State: *functional, testing*
Z 4102e493c8ebe1128af1e89e08e6d79e