release-3.3.1

This release primarily focuses upon being a better network client:

• We avoid fetching the full-contents of every feed when we're executing.
  • Instead we only fetch a feed once at startup.
  • Subsequent fetches will add If-Modified-Since, or Etag headers in our outgoing requests.
  • This should mean that we don't fetch the full contents of feeds that haven't changed unnecessarily.
• Related to this our frequency handling has changed.
  • In the past we used to wake up, between sleeps, every fifteen minutes to process feeds.
  • Now we wake up more often, but we still check feeds at 15minute intervals by default.
  • The new, per-feed, frequency argument will be used to specify the minimum poll-frequency - this can drop to 5 minutes now, but will default to 15 minutes to match past behaviour.
  • It is preferred that feeds which don't change too often will have suitable values configured.
• TLS / SSL failures can be ignored by default
  • Add the new insecure: true setting as a per-feed option to disable certificate checks.
• Feeds with duplicated links will be better handled.
  • We'll attempt to uniquely identify feeds with identical items, via the addition of a # value.
• Finally our logging has been overhauled a little
  • The old LOG_ALL environmental variable has been replaced by a new LOG_LEVEL setting. This allows a finer-grained control of logging output.
  • Also we support a log-file now, by default.

What's Changed

Here's a list of automatically generated notes on merged pull-requests:

• Ignore TLS failures, conditionally. by @skx in #114
• Resolved all the issues found via go-linter by @skx in #116
• Bump go version to 1.17 by @jarkad in #112
• Create docker-publish.yml by @skx in #117
• Bump golang.org/x/net from 0.14.0 to 0.17.0 by @dependabot in #118
• Attempt to uniquify feed items with duplicate URLS by @skx in #120
• 121 logging improvements by @skx in #122
• Allow logging to a file by @skx in #123
• Add arm64 container images by @StayPirate in #125
• Dockerfile improvements by @visit1985 in #110
• Adds youtube template by @faan11 in #127
• Update docker-compose file by @StayPirate in #129
• Do not trigger daily image rebuild by @StayPirate in #130
• Implement support for cached-fetches by @skx in #132
• Added polling-frequency by @skx in #134
• Enable better control of logging levels by @skx in #135

New Contributors

• @jarkad made their first contribution in #112
• @dependabot made their first contribution in #118
• @visit1985 made their first contribution in #110
• @faan11 made their first contribution in #127

Full Changelog: release-3.2...release-3.3

release-3.2

This release corrects a minor issue with Subject: line/header encoding, which should prevent ugly and malformed text being shown.

release-3.1

What's Changed

• Added the ability to encode header entries by @thoka in #108
• Exclude old posts by @thoka in #109
• Resolved all depreciation warnings relating to the ioutil package. by @skx in #104
• Updated all dependencies to resolve some security issues.

New Contributors

• @thoka made their first contribution in #108

Full Changelog: release-3.0...release-3.1

release-3.0

This release removes a lot of the backwards compatibility we've had in place, added as we slowly changed various internals.

To ease maintenance, avoid confusion, and to keep things simple we've now made a clean break with the past:

• The only configuration file processed is that documented in rss2email help config.
  • This is almost certainly ~/.rss2email/feeds.txt, unless you're running upon a Microsoft Windows platform.
• The only location used to record this history of feed-items which have been seen is ~/.rss2email/state.db
  • The directory ~/.rss2email/seen can be removed if it is still present.

release-2.7

This release features a few small additions and tweaks to our behaviour:

• Show the time when sleeping is beginning
  • Implemented by @clh021 in #93.
• Added the Content-Base header to generated eamils
  • Implemented by @StayPirate in #96.
• Minor fixes to internal documentation and CI-system
  • Largely implemented in #87.
• Added the unsee sub-command.
  • This removes a single entry from our history, and was implemented in #88.
  • Later this was updated to allow a regular expression to be specified instead of a literal match.
• Added the env and split functions to the template environment.
  • Reported in #97, implemented in #98.
• Allow a "tag" item to be set for each source-feed, and used in the email template.
  • Reported in #94, implemented in #99.

release-2.6

Changes to State

This release changes the way that we record the feed-items which we've previously seen. In previous releases we maintained a bunch of files beneath ~/.rss2email/seen/, one file for each feed-item we'd processed. As of this release we now use an embedded key/value store, boltdb for that purpose.

When this release is installed for the first time your existing feed-state will be silently and automatically migrated to the new database, which is stored in ~/.rss2email/state.db. This migration will continue up until release-3.0:

This change was implemented in #85, as a result of #82.

In addition to this change we now publish binaries for more platforms upon our release page:

• https://github.com/skx/rss2email/releases/tag/release-2.6

Changes for rss2email 3.x

When rss2email 3.0 is released the automatic migration will go away, as will the automatic update of the feed configuration file. If you install this release, or any future release prior to that then all will be well.

The only users who will be surprised will be those who migration from rss2email v2.5, or lower, to release 3.0 or higher. In that case the state files will not be migrated automatically, and all feed items will be regarded as new/unseen for the first run.

This migration path is documented, and open for discussion, in #86.

release-2.5

This release tries to add some naive rate-limiting:

• If we're fetching a feed from the same hostname as the previous feed-fetch.
  • Then sleep 5 seconds before making the request.

These changes were inspired by #83, and are designed to overcome any simple rate-limiting the remote host might apply to incoming requests.

If you need more than that you may add the per-feed sleep: N option to your feed, which will allow you to specific a different number of seconds to sleep before making the request.

release-2.4

This release updates the handling of the "state" files, which keep track of which remote items have already been seen from within each feed.

In the past we automatically expired older entries from the local state-directory - even if any errors had been encountered in polling the configured feed list.

In this release we avoid pruning the local state files if any errors are observed while fetching the list of feeds that have been configured:

• In the case of no errors, and all feeds being available, nothing will change.
• In the case of transient failures the state files will be pruned upon those runs which don't see errors.
• If you have a feed configured which is 100% broken, and unavailable, then the state-files will continue to exist and consume more space over time.

This was reported in #80, and implemented in #81. In the future release we'll move towards prefixing each state-file with the feed from which it came - which will allow us to expire things accurately, regardless of errors seen or not seen.

release-2.3

This release features the ability to change the recipients of the email-notifications, on a per-feed basis. This was implemented by @avm99963, in #76.

The integrated fuzz-testing of the configuration-file parser was updated to work with the upcoming 1.18 release of the golang compiler/toolset, and is testable using the recently-released 1.18beta1 release.

release-2.2

release-2.2

This release allows the user to use a different email-template on a per-feed basis. This change was implemented as a pull-request by @jcvernaleo.

Other than the new configuration-option there have only been a small number of changes compared to the previous release - I fixed some of the internal implementation to resolve 100% of the "complexity" issues reported upon the go report card, allowing the application to receive a perfect score.