Release Management & Versioning

[grayside]

We would like to publish release notes and maintain versioning for the samples guide to ensure we have a clear mechanism for communicating updates.

• Release notes should recognize all kinds of contributions, but we are only interested in versioning the samples guide content
• Release notes should leverage DPE release tooling & conventions where possible
• Release notes should separate content changes (of general interest) from site infrastructure changes (mainly interesting for contributors)

Proposal

• Use https://github.com/google-github-actions/release-please-action to automate release creation and version updates
• Use GitHub's automatically generated release notes (separate content & site changes)
  • Categories like Breaking, Guide Updates, Infrastructure Changes, Other Work
• Use https://github.com/bcoe/conventional-release-labels to apply conventional commit directives in PR titles as PR labels
• Use https://github.com/actions/labeler to automatically apply content, site, and automation labels:
  • .github/** => automation
  • content/** => content
  • layouts/*, package, config.toml => site

This would address some of the label consideration in #37

[dandhlee]

In terms of the samples style guide, if we plan on using conventional commits, what constitutes something like a fix versus feat? What would be a "breaking change" for Samples?

[grayside]

Here's my thought process:

• fix: clarify a guideline or correct a buggy sample
• feat: new rule or implication of an existing rule
• breaking: contradicting a previous rule

If this feels awkward, we can explore alternatives.

[dandhlee]

SGTM.