Bump the actions-deps group with 2 updates

[dependabot]

Bumps the actions-deps group with 2 updates: opencontainers/distribution-spec and crate-ci/typos.

Updates opencontainers/distribution-spec from eeddb235239ccfd57d40a4338853260ed2081266 to 7872490e9d4943b20f11e21475bc13fd2e02b7d8

Changelog

Sourced from opencontainers/distribution-spec's changelog.

Releases

The release process hopes to encourage early, consistent consensus-building during project development. The mechanisms used are regular community communication on the mailing list about progress, scheduled meetings for issue resolution and release triage, and regularly paced and communicated releases. Releases are proposed and adopted or rejected using the usual project governance rules and procedures.

An anti-pattern that we want to avoid is heavy development or discussions "late cycle" around major releases. We want to build a community that is involved and communicates consistently through all releases instead of relying on "silent periods" as a judge of stability.

Parallel releases

A single project MAY consider several motions to release in parallel. However each motion to release after the initial 0.1.0 MUST be based on a previous release that has already landed.

For example, distribution-spec maintainers may propose a v1.0.0-rc2 on the 1st of the month and a v0.9.1 bugfix on the 2nd of the month. They may not propose a v1.0.0-rc3 until the v1.0.0-rc2 is accepted (on the 7th if the vote initiated on the 1st passes).

Specifications

The OCI maintains three categories of projects: specifications, applications, and conformance-testing tools. However, specification releases have special restrictions in the [OCI charter][charter]:

• They are the target of backwards compatibility (§7.g), and
• They are subject to the OFWa patent grant (§8.d and e).

To avoid unfortunate side effects (onerous backwards compatibility requirements or Member resignations), the following additional procedures apply to specification releases:

Planning a release

Every OCI specification project SHOULD hold meetings that involve maintainers reviewing pull requests, debating outstanding issues, and planning releases. This meeting MUST be advertised on the project README and MAY happen on a phone call, video conference, or on IRC. Maintainers MUST send updates to the dev@opencontainers.org with results of these meetings.

Before the specification reaches v1.0.0, the meetings SHOULD be weekly. 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.

The release plans, corresponding milestones and estimated due dates MUST be published on GitHub (e.g. https://github.com/opencontainers/distribution-spec/milestones). GitHub milestones and issues are only used for community organization and all releases MUST follow the project governance rules and procedures.

Timelines

Specifications have a variety of different timelines in their lifecycle.

• Pre-v1.0.0 specifications SHOULD release on a monthly cadence to garner feedback.
• Major specification releases MUST release at least three release candidates spaced a minimum of one week apart. This means a major release like a v1.0.0 or v2.0.0 release will take 1 month at minimum: one week for rc1, one week for rc2, one week for rc3, and one week for the major release itself. Maintainers SHOULD strive to make zero breaking changes during this cycle of release candidates and SHOULD restart the three-candidate count when a breaking change is introduced. 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.
• Minor and patch releases SHOULD be made on an as-needed basis.

... (truncated)

Commits

• 7872490 Merge pull request #561 from sudo-bmitch/pr-v1.1.1
• 812fc5b Merge pull request #562 from sudo-bmitch/pr-release-specs
• e032387 Add a release step for specs.opencontainers.org
• f1286ee version: bump back to +dev
• a139cc4 version: release v1.1.1
• See full diff in compare view

Updates crate-ci/typos from 1.29.0 to 1.29.5

Release notes

Sourced from crate-ci/typos's releases.

v1.29.5

[1.29.5] - 2025-01-30

Internal

• Update a dependency

v1.29.4

[1.29.4] - 2025-01-03

v1.29.3

[1.29.3] - 2025-01-02

v1.29.1

[1.29.1] - 2025-01-02

Fixes

• Don't correct deriver

Changelog

Sourced from crate-ci/typos's changelog.

[1.29.5] - 2025-01-30

Internal

• Update a dependency

[1.29.4] - 2025-01-03

[1.29.3] - 2025-01-02

[1.29.2] - 2025-01-02

[1.29.1] - 2025-01-02

Fixes

• Don't correct deriver

Commits

• 11ca458 chore: Release
• 99fd37f docs: Update changelog
• 4f604f6 Merge pull request #1220 from epage/w7
• ba04a1a perf: Remove ErrMode overhead
• 60452b5 chore: Update to Winnow 0.7
• 4c22f19 refactor: Migrate from Parser to ModalParser
• 7830eb8 refactor: Resolve deprecations
• 07f1292 chore: Upgrade to Winnow 0.6.26
• 3683264 chore(deps): Update Rust Stable to v1.84 (#1216)
• 2ed38e0 chore(deps): Update Rust crate bstr to v1.11.3 (#1202)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions