When version histories are supplied using structured formats like RSS, Atom, or JSON Feed, implementors will need to parse that data and render it into a web page. This document suggests how that should be done, with a focus on key fields for each history item.
This identifies the purpose of the version history page. Alternatively, this could be the name of the app (taken from the Manifest) plus the text "Version History".
h1rss > channel > titlefeed > titleobject["title"]Valid RSS feeds will have descriptions, but neither Atom nor JSON Feed require it. Exposing this information should be considered optional.
p,div, ordocumentFragment (if the description contains flow-level elements).rss > channel > descriptionfeed > description (if present)object["description"] (if present)Each item in a version history should exist as a flow-level sectioning HTML element.
article,section, ordetailsrss > channel > item (each item is a history item)feed > entry (each entry is a history item)object["items"] (each object in this array is a history item)This is a string that names the given version. In some apps it may be numeric, in others it may be a string, but for the purposes of the parser, it should be considered to be a string and would likely be rendered into a heading element.
h2,summary (if details is used for an item),rss > channel > item > titlefeed > entry > titleobject["items"][0].title falling back to object["items"][0].idThis is a string that describes significant changes in this version.
p,div, ordocumentFragment (if the description contains flow-level elements).rss > channel > item > descriptionfeed > entry > content falling back to feed > entry > summaryobject["items"][0].content_html or object["items"][0].content_text (one of these must be present to be valid)This is a representation of when the version was released and is optional.
timerss > channel > item > pubDatefeed > entry > publishedobject["items"][0].date_published