-
Notifications
You must be signed in to change notification settings - Fork 286
Open
Labels
💬 team discussion🧽 choreAdministrative task: documentation, build, test, release, git, etc.Administrative task: documentation, build, test, release, git, etc.
Description
Potential GitHub/git commit, branch & tag protections:
Tags
- Redo version tags without
v
prefix?- Tags (
mas-cli/mas
&mas-cli/homebrew-tap
) - GitHub Releases (
mas-cli/mas
&mas-cli/homebrew-tap
)- Tag
- Name
- Body
- Custom tap formula (
mas-cli/mas
&mas-cli/homebrew-tap
) homebrew-core
formula- …?
- Tags (
- Configure & enable tag ruleset
- Disallow changing version tags.
- Ensure that each new release tag 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
- So, the following version transitions are OK:
- Allow creating version tags outside
main
only 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 possiblyp1.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
- Version tag:
- Create a legacy version patch branch rooted on the version-tagged
Commits:
- Require signed commits?
- Require commit sign offs?
- Require
Resolve #…
in last PR commit message? - Require
Partial #…
in prior PR commit messages?
Done
- Require signed annotated tags
- Enforced by
.githubs/workflows/tag-pushed.yml
. - Doesn't use
tag.gpgSign
.
- Enforced by
- Disallow creating version tags outside
main
.
Metadata
Metadata
Assignees
Labels
💬 team discussion🧽 choreAdministrative task: documentation, build, test, release, git, etc.Administrative task: documentation, build, test, release, git, etc.