# Don't call us, we call you

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
    <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
    <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
    <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
    <br> <small>convenient</small>
  </th>
  <td>
    Projects on Github can be automatically queried for tagged
    As unlovely fallback a commit log will substitute and be condensed into a change summary.
  </td>
</tr>

<tr>
  <th>
    <a
    <br>
  </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. is still home to many projects).
  </td>
</tr>

<tr>
  <th>
    <a
    <br>
  </th>
  <td>
    LaunchPad projects will be queried per API. It strictly depends on a populated `release_notes` entry.
  </td>
</tr>

<tr>
  <th>
    Debian
    <br>
  </th>
  <td>
    Adds a changelog variation for debian/changelog files. (Just a variation of plain changelogs. Technically they're package release logs. Added this reluctantly. But they're still common enough to warrant support.)
  </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.