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 [email protected] (@crosbymichael)
• Mrunal Patel [email protected] (@mrunalp)
• Daniel, Dao Quang Minh [email protected] (@dqminh)
• Tianon Gravi [email protected] (@tianon)
• Qiang Huang [email protected] (@hqhq)
• Aleksa Sarai [email protected] (@cyphar)
• Giuseppe Scrivano [email protected] (@giuseppe)
• Akihiro Suda [email protected] (@AkihiroSuda)
• Kir Kolyshkin [email protected] (@kolyshkin)
• Sebastiaan van Stijn [email protected] (@thaJeztah)
• Toru Komatsu [email protected] (@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 [email protected]
	* [ ] 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 [email protected] 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 ㊗️