Add site.feed.updated = latest_post setting

[Krinkle]

Two main uses cases:

1. Reduce deployment churn in repositories that hold a docsite in
   addition to source code. These currently regenerate and find
   something new commit on every change, even when nothing in the
   site has been changed. The only file changing each time is
   feed.xml.
   For example: https://github.com/qunitjs/qunit/commits/gh-pages

2. Improve reproducibility of the build, as highlighted via
   Respect SOURCE_DATE_EPOCH environment variable (if set) over Time.now jekyll#7187,
   by offering a choice that simply eliminates use of current time entirely,
   not even having to mock it.

[parkr]

Boolean config options are always restrictive. What if we went with something that allowed the user to decide from one of a list of values? Like feed.updated: latest_post would choose the publish time of the latest post, and feed.updated: site_time (default) would be site.time. Something like that, the values could change but it would grant more freedom in the future.

[parkr]

Cc @vincerubinetti and #387

[michaelnordmeyer]

That's a very good idea and I would love to have the feed's <updated> tag have the newest date of all the posts in the feed, but unfortunately a build could have been triggered because the title of the site or anything else non-post-related but feed-included has changed.

The Atom spec states (emphasis mine):

The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant.

To make sure that all the other non-entry tags haven't changed since the last build, they have to be cached and compared, which at least Jekyll doesn't do.

[Krinkle]

The Atom spec says <updated> should only be incremented when the change is "significant":

[…] in a way the publisher considers significant.

Jekyll does not follow this by default, either.

Afaik feed readers don't even use this field. To detect or apply changes, HTTP semantics (Last-Modified/E-Tag, If-Modified-Since) and checksums are used. In theory, this field exists to convey to humans (not machine) after a "significant" change was made. This is subjective of course, and is rarely used in the interface of a feed reader.

Part of why this is rare, might be because of site generators like Jekyll that update it constantly! This makes it no longer a useful signal. Feed readers now have their own concept of unread/new/updated to decide how/when to draw attention to a feed you have subscribed to. They might also display when they last checked a feed, which does not depend on this field either.

Most feed readers also don't display the site description. And the site name is not read from the feed each time, but only once when you first create the subscription. This has the benefit of letting you find what you added, instead of the name changing automatically.

I believe the following funnel is required for this to matter:

• A feed reader that actually uses the <updated> field.
• And, a feed reader that actually displays the site name or site description from the latest fetch of the feed each time.
• And, one of:
  • A site that has a dormant blog, and is making a change to the site name or description, and wants feed readers to notify their subscribers of this change in the site name or description.
  • A site that has a blog that publishes less than daily, but wants feed readers to draw subscriber attention as soon as possible to the new name/description (instead of when the next post is published).

Anyway, this PR doesn't change the default.

All I'm adding is the option to use site.feed.updated = "latest_post" for people who want to reduce noise in CI/diffs, and (in theory) reduce visual noise in feed readers that support this mechanism as it would almost always be undesirable and harm your site's reputation.