You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: RELEASES.md
+11-8Lines changed: 11 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,12 +29,12 @@ To avoid unfortunate side effects (onerous backwards compatibility requirements
29
29
30
30
Every OCI specification project SHOULD hold meetings that involve maintainers reviewing pull requests, debating outstanding issues, and planning releases.
31
31
This meeting MUST be advertised on the project README and MAY happen on a phone call, video conference, or on IRC.
32
-
Maintainers MUST send updates to the dev@opencontainers.org with results of these meetings.
32
+
Maintainers MUST send updates to the <dev@opencontainers.org> with results of these meetings.
33
33
34
34
Before the specification reaches v1.0.0, the meetings SHOULD be weekly.
35
35
Once a specification has reached v1.0.0, the maintainers may alter the cadence, but a meeting MUST be held within four weeks of the previous meeting.
36
36
37
-
The release plans, corresponding milestones and estimated due dates MUST be published on GitHub (e.g. https://github.com/opencontainers/runtime-spec/milestones).
37
+
The release plans, corresponding milestones and estimated due dates MUST be published on GitHub (e.g. <https://github.com/opencontainers/runtime-spec/milestones>).
38
38
GitHub milestones and issues are only used for community organization and all releases MUST follow the [project governance](GOVERNANCE.md) rules and procedures.
39
39
40
40
### Timelines
@@ -48,8 +48,6 @@ Specifications have a variety of different timelines in their lifecycle.
48
48
For example if a breaking change is introduced in v1.0.0-rc2 then the series would end with v1.0.0-rc4 and v1.0.0.
49
49
* Minor and patch releases SHOULD be made on an as-needed basis.
@@ -65,14 +63,15 @@ Releases usually follow a few steps:
65
63
*[ ] drop hash and indent, `:'<,'> s/^\w* /^I* /`
66
64
*[ ] a commit bumping `./specs-go/version.go` to next version and empty the `VersionDev` variable
67
65
*[ ] a commit adding back the "+dev" to `VersionDev`
68
-
*[ ] send email to dev@opencontainers.org
66
+
*[ ] send email to <dev@opencontainers.org>
69
67
*[ ] copy the exact commit hash for bumping the version from the pull-request (since master always stays as "-dev")
70
68
*[ ] count the PRs since last release (that this version is tracking, in the cases of multiple branching), like `git log --pretty=oneline --no-merges --decorate $priorTag..$versionBumpCommit | grep \(pr\/ | wc -l`
71
69
*[ ] get the date for a week from now, like `TZ=UTC date --date='next week'`
72
70
*[ ] OPTIONAL find a cute animal gif to attach to the email, and subsequently the release description
73
71
*[ ] subject line like `[runtime-spec VOTE] tag $versionBumpCommit as $version (closes $dateWeekFromNowUTC)`
74
72
*[ ] email body like
75
-
```
73
+
74
+
```text
76
75
Hey everyone,
77
76
78
77
There have been $numPRs PRs merged since $priorTag release (https://github.com/opencontainers/runtime-spec/compare/$priorTag...$versionBumpCommit).
0 commit comments