### Check existing issues - [x] I've verified that this request isn't described by any existing issues. ### Request ### **Feature Request** We would like a mechanism (for example via `craftctl set version`) to **dynamically update the top-level `version:` field** in `rockcraft.yaml` during the build. Currently, the top-level `version:` field is static, and there is no supported way to override it dynamically. Being able to set it during the build would allow the rock version to be computed from a combination of upstream workload version plus packaging increment (rock revision). ### The problem it solves ### **Problem / Use Case** Suppose we are packaging Mattermost 10.11.6 with a local packaging increment (rock revision 1). We define the version in a single external file or CI variable: ```bash # version.env WORKLOAD_VERSION=10.11.6 ROCK_REV=1 ROCK_VERSION="${WORKLOAD_VERSION}-${ROCK_REV}" ``` During the build, we dynamically set the top-level rock version and reference the workload version in all parts: ```bash # dynamically set top-level version craftctl set version=$ROCK_VERSION ``` ```yaml parts: backend: source: https://releases.mattermost.com/$WORKLOAD_VERSION/mattermost-$WORKLOAD_VERSION-linux-amd64.tar.gz webapp: source-tag: v$WORKLOAD_VERSION ``` Benefits: * The **workload version is defined once**, outside the rock * The **top-level version automatically includes the rock revision** * All parts reference the workload version consistently, avoiding duplication * Incrementing the rock revision produces a new rock version without changing upstream references