GitHub branch & tag protections:

• Require signed annotated tags (tag.gpgSign)?
  • Or use lightweight tags instead?
• Disallow changing version tags.
• Disallow creating version tags outside main:
  • Except if we create patches for legacy versions if newer versions require a newer macOS, in which case we'd:
    • Create a legacy version patch branch rooted on the version-tagged main revision that is being patched.
    • Require that the branch be named following a convention relating it to the version tag.
    • Require that all version tags on the patch branch monotonically increasing patch versions, e.g.:
      • Version tag: v1.8.6
      • Patch branch: b1.8.6 (b for branch), or possibly p1.8.6 (p for patch), or something similar
      • Acceptable patch tags on b1.8.6:
        • v1.8.6.1-alpha.1
        • v1.8.6.1-beta.1
        • v1.8.6.1-beta.2
        • v1.8.6.1
        • v1.8.6.2
        • …
      • Rejected tags for p1.8.6:
        • v1.8.5
        • v1.8.7
        • v1.9.0
        • v2.0.0
• Ensure that each new release has one & only one semantic version component that is one greater than some other prior release version, followed by zeros for all subsequent components, with an optional -beta.1 suffix.
  • So, the following version transitions are OK:
    • 5.6.7 -> 6.0.0
    • 5.6.7 -> 5.7.0
    • 5.6.7 -> 5.6.8
    • 5.6.7 -> 5.6.8-beta.1
    • 5.6.7-beta.1 -> 5.6.7-beta.2
  • While the following version transitions are not OK:
    • (no stable 5.* exists) -> 6.0.0
    • (no stable 5.6.* exists) -> 5.7.0
    • (no stable 5.6.7.* exists) -> 5.6.8
    • (no stable 5.6.7.* exists) -> 5.6.8-beta.1
    • (no 5.6.7-beta.1 exists) -> 5.6.7-beta.2