Use this guide when the release refreshes Query Service.
The recommended workflow is:
wbs-dev update wdqs
The command:
query-service-parent-* tag.WDQS.version in docker-bake.hcl, drafts the changelog, asks the operator to confirm the image version, and leaves every change unstaged for review with git diff.Prefer a version already exercised in Wikidata production. Ask the upstream maintainers when storage or RWStore.properties compatibility is unclear.
The same update can be prepared manually:
WDQS.version from docker-bake.hcl and inspect newer query-service-parent-* tags.query-service-parent-<WDQS_VERSION>.service-<version>-dist.tar.gz and its .md5 checksum are available from the Wikimedia package registry path used by the Dockerfile.WDQS.version to the selected version and review the resulting diff.Check for incompatible API, configuration, Java, Blazegraph, storage, or data reload requirements.
The upstream Query Service version does not reliably indicate whether an update is breaking for this image, and major image releases have rarely been necessary. Review the upstream diff and keep the current image major unless there is a clear incompatibility in APIs, required configuration or environment variables, stored data, or operator actions. Apply the shared versioning policy to compatible changes.
wbs-dev update does not select the Java or Debian images in docker-bake.hcl. When reviewing them:
PrintGCDateStamps option, or verify and test the corresponding script changes as part of the update. Review Query Service and Blazegraph compatibility before changing the JRE.bash, gettext, curl, certificate, user-management, and archive-fetching behavior and run the Query Service integration tests. A Debian update is not required merely because a newer stable release exists.