[dependabot]

Bumps the minor-and-patch group with 1 update: lukka/get-cmake.

Updates lukka/get-cmake from 4.4.2 to 4.4.4

Changelog

Sourced from lukka/get-cmake's changelog.

Release Process for get-cmake

This document describes the release process for the get-cmake action after a new CMake or Ninja version has been merged to the main branch.

Overview

The get-cmake action uses two key reference points for users:

1. latest branch - Points to the most recent stable release
2. Version tags (e.g., vX.Y.Z or ninja-vX.Y.Z) - Allow users to pin to specific catalog snapshots

When a new stable CMake, CMake release candidate, or Ninja version is merged to main via automated PR, a release is performed automatically (or can be done manually). Release detection and notes use fixed rules, without an LLM.

Release formats and tag policy

The shared publisher, .github/scripts/publish-release.js, compares these version markers:

Component	Version marker	Title entry	Notes
Stable CMake	.latest_cmake_version	CMake vX.Y.Z	New latest CMake version and one-line action usage
CMake RC	.latestrc_cmake_version	CMake vX.Y.Z-rcN	New latestrc version and usage with cmakeVersion: latestrc
Ninja	.latest_ninja_version	Ninja vX.Y.Z	New Ninja version available through @latest

Combined updates produce one release: title entries are joined with and, and the notes contain a separate entry for each changed component. For example, CMake v3.29.5 and CMake v3.30.0-rc1 follows the historical combined format. RC-only notes follow the historical RC format, rather than claiming the default CMake version changed.

Tag selection is deterministic:

1. If stable CMake changed, use v<CMake version>.
2. Otherwise, if Ninja changed, use ninja-v<Ninja version>. This also applies to combined Ninja + RC updates and avoids reusing an unchanged stable CMake tag.
3. Otherwise, use v<CMake RC version> and mark the release as a GitHub prerelease.

Combined updates containing stable CMake or Ninja are not marked as prereleases. An RC marker that resolves to the stable CMake version is not announced as a separate RC update. Without changed markers or an explicit matching recovery tag, the publisher makes no release, tag, or latest branch changes.

Release titles and tagged catalog versions describe the release target. Usage notes for @latest and cmakeVersion: latestrc use the markers from current main, which is where the moving latest branch is synchronized. When recovering an older catalog, notes distinguish its versions from the versions currently selected by those aliases.

Release Steps

Option 1: Automatic Release (Recommended)

The auto-release.yml workflow automatically handles releases when version markers change on main, including merged automated tool version PRs:

1. When a push to main changes any of the three version markers
2. The workflow automatically:
   • Compares all three markers between the push's before and after commits
   • Generates the title, notes, tag, and prerelease status using the rules above
   • Updates the latest branch to match main
   • Creates an annotated version tag at the exact pushed commit (if it doesn't exist)
   • Publishes a GitHub release with the generated title and notes

Detection does not depend on PR titles and covers merge commits, squash merges, multi-commit rebase merges, and direct version updates on main. Using the push's exact commit range prevents a later merge from changing the versions announced by a queued release. The moving latest branch still tracks current main.

... (truncated)

Commits

• a89e43e New CMake version(s): cmake-v4.4.4
• e22dd04 Restrict catalog PR creation to main
• df5af53 Namespace the cache entries by a collision resistant digest
• d520f90 Prove that the CMake manifest does list every tracked asset
• 2bc13fd Feed the hasher explicitly instead of ending it as a pipeline destination
• a4ab8fe Fail catalog generation when a release publishes no checksum of its own
• 0661582 Namespace the cache key and reject unverifiable packages before any lookup
• 25048e9 Rebuild dist/
• e1ba19e Document the integrity verification of the downloaded archives
• f3fcbbb Fail the build when dist/ is out of sync with the sources
• 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 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