Description
The Release
struct has fields needed to describe a Go release, including a high-level summary of the release content:
Quantifier string // Optional quantifier. Empty string for unspecified amount of fixes (typical), "a" for a single fix, "two", "three" for multiple fixes, etc.
Components []template.HTML // Components involved. For example, "cgo", "the <code>go</code> command", "the runtime", etc.
Packages []string // Packages involved. For example, "net/http", "crypto/x509", etc.
With the previous Go security policy, each minor release was either a bug-fix minor release, or a security minor release, so it was viable to capture that with a single boolean:
Security bool // whether this is a security release
With the current Go security policy (#44918), a Go release may include only bug fixes, only security fixes, or both at once. The last case can't be represented with the current fields, and so the CustomSummary
escape hatch has been used so far whenever a minor release included both bug- and security fixes.
Compared to listing components and packages, writing the entire custom summary is more tedious and error prone due to English grammar, and defeats the purpose of having those fields separated out (previously motivated in #38488). The past releases that used CustomSummary
followed a consistent pattern, so it's viable to update them to a new representation without significant changes. This is the tracking issue for that.
I've prototyped a fix and will send it via two CLs: the first one adds test data to cover recent releases, and the second changes the struct while updating the test data accordingly (it's mostly changes in whitespace, some trivial grammar diffs and minor intentional fixups).
CC @golang/release, @golang/security.
Metadata
Metadata
Assignees
Type
Projects
Status