Release v1.3.0

[AkihiroSuda]

Fix #1295

---

This release requires a two-thirds majority maintainers vote (8 of 11).
The voting will close at Tue Nov 4 05:00:00 UTC 2025.

• Michael Crosby michael@docker.com (@crosbymichael)
• Mrunal Patel mpatel@redhat.com (@mrunalp)
• Daniel, Dao Quang Minh dqminh89@gmail.com (@dqminh)
• Tianon Gravi admwiggin@gmail.com (@tianon)
• Qiang Huang h.huangqiang@huawei.com (@hqhq)
• Aleksa Sarai asarai@suse.de (@cyphar)
• Giuseppe Scrivano gscrivan@redhat.com (@giuseppe)
• Akihiro Suda akihiro.suda.cz@hco.ntt.co.jp (@AkihiroSuda)
• Kir Kolyshkin kolyshkin@gmail.com (@kolyshkin)
• Sebastiaan van Stijn github@gone.nl (@thaJeztah)
• Toru Komatsu k0ma@utam0k.jp (@utam0k)

[kolyshkin]

lgtm (with or without the freebsd pr)

[hqhq]

LGTM

[giuseppe]

LGTM

[utam0k]

LGTM 🚀

[kolyshkin]

@tianon @thaJeztah @dqminh PTAL

[tianon]

I do wish we'd waited a little longer on FreeBSD, but it's good enough; LGTM

[mrunalp]

LGTM

[kolyshkin]

@thaJeztah @crosbymichael @dqminh PTAL

[thaJeztah]

🙈 sorry, thought I LGTM'd already, but had the tab still open 😆

LGTM

[utam0k]

🎉 The release requirements have been met. 9/11

[AkihiroSuda]

Rebased to include

• Mention FreeBSD platform #1304

[cyphar]

I guess that's fine but technically according to GOVERNANCE the release request is for a specific commit so maybe let's avoid doing that in the future? (It also says that we need to do votes by email, we should probably update that...)

Did you want to prepare the release artefacts @AkihiroSuda?

[AkihiroSuda]

I guess that's fine but technically according to GOVERNANCE the release request is for a specific commit

It seems an "example" "usually"

runtime-spec/GOVERNANCE.md

Lines 66 to 68 in 6acd32d

	For example:
	> [runtime-spec adopted]: Tag 0647920 as 1.0.0-rc (+6 -0 #3)

runtime-spec/RELEASES.md

Lines 55 to 73 in 6acd32d

	Releases usually follow a few steps:
	* [ ] prepare a pull-request for the release
	* [ ] a commit updating `./ChangeLog`
	* [ ] `git log --oneline --no-merges --decorate --name-status v1.0.1..HEAD | vim -`
	* [ ] `:% s/(pr\/\(\d*\))\(.*\)/\2 (#\1)/` to move the PR to the end of line and match previous formatting
	* [ ] review `(^M|^A|^D)` for impact of the commit
	* [ ] group commits to `Additions:`, `Minor fixes and documentation:`, `Breaking changes:`
	* [ ] delete the `(^M|^A|^D)` lines, `:%!grep -vE '(^M|^A|^D)'`
	* [ ] merge multi-commit PRs (so each line has a `(#num)` suffix)
	* [ ] drop hash and indent, `:'<,'> s/^\w* /^I* /`
	* [ ] a commit bumping `./specs-go/version.go` to next version and empty the `VersionDev` variable
	* [ ] a commit adding back the "+dev" to `VersionDev`
	* [ ] send email to dev@opencontainers.org
	* [ ] copy the exact commit hash for bumping the version from the pull-request (since master always stays as "-dev")
	* [ ] 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`
	* [ ] get the date for a week from now, like `TZ=UTC date --date='next week'`
	* [ ] OPTIONAL find a cute animal gif to attach to the email, and subsequently the release description
	* [ ] subject line like `[runtime-spec VOTE] tag $versionBumpCommit as $version (closes $dateWeekFromNowUTC)`

so maybe let's avoid doing that in the future?

Can we relax this rule?

(It also says that we need to do votes by email, we should probably update that...)

"SHOULD", not "MUST"

runtime-spec/GOVERNANCE.md

Line 11 in 6acd32d

A maintainer SHOULD propose a motion on the dev@opencontainers.org mailing list (except [security issues](#security-issues)) with another maintainer as a co-sponsor.

Did you want to prepare the release artefacts @AkihiroSuda?

Yes

[cyphar]

Can we relax this rule?

We can definitely have a discussion about it, but in my view the reason for the rule is to:

1. Make sure everyone is on the same page about what exactly is being proposed for release.
2. Avoid situations where someone merges something and includes it in the release without the requisite threshold for approval to end up in a release.

If we feel that these are not practical problems then we can relax this rule, but then it's not clear to me what purpose the 2/3rd majority would serve -- yes, if maintainers object to a release happening at all then it will be blocked, but if they agree to a release then you only need 2 LGTMs to merge something else and rebase the PR. In that case we might as well just only require 2 LGTMs for releases (like we do in runc now) and simply provide an opportunity for other maintainers to voice concerns before we release.

Personally I think the spec repos should be more strict about governance rules than repos like runc and umoci, purely because once we ship something in a spec it is far more permanent than in software projects.

But again, I don't think anyone would object to #1304 being included, this is more of a meta-point about the process.

"SHOULD", not "MUST"

Sure, and I don't mind doing it on GitHub instead but (again) the general flow is meant to be that we have a specific commit we are voting on -- while this information is theoretically provided by GitHub we don't make use of the "dismiss stale reviews" feature in this repo. Obviously if we drop this requirement then this doesn't matter either.

[tianon]

Agreed/seconded that #1304 is fine and that we should avoid that in the future without resetting the vote.

[utam0k]

BTW, who's going to handle preparing the release blog post?

[AkihiroSuda]

BTW, who's going to handle preparing the release blog post?

Shall I write it, or is anybody interested in?

[utam0k]

I'm busy this month because I have my wedding 🙏 I might do the next release.

[AkihiroSuda]

I'm busy this month because I have my wedding 🙏 I might do the next release.

Congratulations ㊗️

[AkihiroSuda]

Merging to unblock runc v1.4 and will draft the blog ASAP.

[AkihiroSuda]

Blog:

• blog: Add "OCI Runtime Spec v1.3" opencontainers.org#163