D 2016-05-05T02:16:16.328
L Autoupdate
N text/x-markdown
P ab4960888c45c327f504c463d76eb94d56a1be57
U mario
W 3111
# Don't call us, we call you
[freshcode.club](http://freshcode.club) can automate your release announcements. After submitting the initial project description, one of the update modules can be used.
<table style="border-spacing: 5pt 15pt;">
<tr>
<th>
<a href="wiki/releases.json">releases.json</a>
<br> <small>coherent</small>
</th>
<td>
With a simple <em>JSON</em> format, a complete project release history
can be kept. It's the most robust and detailed option to automate
announcements.
</td>
</tr>
<tr>
<th>
<a href="wiki/AutoupdateChangelog">Changelog</a>
<br> <small>simple</small>
</th>
<td>
Using an existing Changelog / News.txt file is often possible. It
just needs coherent formatting and plain text or Markdown or RST
syntax and structure.
</td>
</tr>
<tr>
<th>
<a href="wiki/AutoupdateRegex"><nobr>Regex/jQuery</nobr></a>
<br> <small>versatile</small>
</th>
<td>
Screen scraping is an unsuspectedly simple way to extract changelogs
from project websites. Simple rule sets allow using <em>XPath</em> or
<em>jQuery</em> selectors and/or narrowing it down with <em>regular
expressions</em>.
</td>
</tr>
<tr>
<th>
<a href="wiki/AutoupdateGithub">GitHub</a>
<br> <small>convenient</small>
</th>
<td>
Projects on Github can be automatically queried for tagged <em>/releases</em>.
As unlovely fallback a commit log will substitute and be condensed into a change summary.
</td>
</tr>
<tr>
<th>
<a href="wiki/AutoupdateSourceforge">Sourceforge</a>
<br> <small>testing</small></s>
</th>
<td>
Sourceforge projects can use their news/blog for announcing releases.
Any post containing a version number in the title is assumed to be a
changelog. (Sf.net is still home to many projects).
</td>
</tr>
<tr>
<th>
<a href="wiki/AutoupdateLaunchpad">Launchpad</a>
<br> <small>new</small></s>
</th>
<td>
LaunchPad projects will be queried per API. It strictly depends on a populated `release_notes` entry.
</td>
</tr>
<tr>
<th>
<a href="wiki/AutoupdateDebian">Debian</a>
<br> <small>test</small></s>
</th>
<td>
Adds a changelog variation for debian/changelog files.
</td>
</tr>
</table>
In conjunction to that, all project listings support [`$version` placeholders](wiki/$version+placeholder) in URLs already, alleviating some manual editing.
And if preferred, there is even the [Freecode JSON API](wiki/Freecode+JSON+API) and a `freshcode-submit` command-line utility.
Regardless of the source used, a user-oriented writing style for release notes is most important. Developer and version control commit logs don't usually convey new features and their significance. Basic filtering is applied to most sources (such as stripping `fixed bug #123` or `Merged pull request..` etc.)
There are some general fields such as `exclude = 1.2.3` and `interval = 14` (in days) that work in the regex/rules field regardless of autoupdate module.
Z b16d0328239b71b8a80e2e447e65a5bc