### Proposed Wikibase Suite Extension MVP

February 5th 2026

I think we should extend Adam’s work in [#901](https://github.com/wmde/wikibase-release-pipeline/pull/901) to capture version/build provenance for diagnostics and metadata use.

Initially I was leaning toward keeping only the `Special:Version` > "Installed software" approach from PR #901, and that is still a solid base. We should gather and set the following versions automatically at build time:

- Wikibase Suite Docker Image (https://www.mediawiki.org/wiki/Wikibase/Suite): `<wikibase image version>`
- Wikibase Suite Build Tools (https://github.com/wmde/wikibase-release-pipeline): `<pipeline git sha>` (build tools revision used to build the image)

And set the following manually when we update `deploy/package.json` during release:

- Wikibase Suite Deploy (https://www.mediawiki.org/wiki/Wikibase/Suite/Deploy): `<deploy version>` (only when Deploy is used)

I also propose we expose a small, flat JSON document to avoid HTML parsing and provide a non-scraping access path to running versions:

`http://<base-wiki-url>/wbs-versions.json` (e.g. `https://example.org/wbs-versions.json`)

That endpoint would return something that looked like this:

{
  "wikibase_image_version": "5.0.0",
  "deploy_version": "5.0.1",
  "pipeline_git_sha": "cc32494ebf8a"
}

## Updated implementation recommendation

After looking more closely at the effort and implications, I now recommend we implement this as a proper "Wikibase Suite" extension rather than only hook-based row insertion.

Why this shift:

- Hook-only insertion is fine for displaying rows, but gives us less leverage for product-facing Wikibase Suite functionality which I think we have some clear cases for upcoming.
- A full extension gives us a clean native place for Wikibase Suite capabilities in the image (versions display, participation actions, future additions).
- Scope increase appears minimal; this remains within the same expected timeline.
- We still keep `wbs-versions.json`, so we have a robust non-scraping path regardless.

In short: extension-first gives us a better foundation now, with little/no consequential extra scope.


## Announce (callback) feature

I would also like us to consider adding an Announce (callback) feature in this extension in the same workstream. This feature would only appear when the admin user was logged in.

This is achievable with also only small extra effort and maintains the same timeline for delivery, and I think aligns naturally with an extension-based “Wikibase Suite” surface. With this feature added users who initially opt out of announcing their Wikibase during initial install, can later choose to which we could promote or publicize.


## Estimated Engineering Effort

1–2 days + code review time (still the expected range, including extension-first implementation and Announce).

## Notes

- I don't think we should attempt to report versions of adjacent services (WDQS, QuickStatements, Elasticsearch, MariaDB) for now. While we could add custom code for version reporting to each image, their endpoints are not predictable or necessarily published, and passing their versions into the Wikibase container via Docker Compose would be unreliable if users customize compose (values can go missing or become incorrect). By contrast, Wikibase image version is intrinsic to the container, and Deploy version is a single explicit signal when running via the Deploy stack. In an unmodified standard Deploy setup, other versions can generally be inferred from the Build Tools (pipeline) commit hash we report.
- The existing pingback/callback registers new instances with the metadata service on first install. With `wbs-versions.json`, the metadata service can deterministically fetch versions from the base URL it already knows. We could also or instead include version fields directly in the callback payload to avoid this extra request, but that would require a minor change to the Wikibase Metadata endpoint (GraphQL) to optionally expect those fields. This is not required for this phase, but still low-effort if we decide it is worthwhile.
- Analytics permissioning is another thing that could be combined as part of the Announce feature I am recommending we add. I have a mock-up for discussion on that now or later, but adding this would add some additional scope as it would require a decision about our analytics platform and/or extension to our Wikibase Metadata project to capture this additional setting.

## Recommendation

Proceed with a full Wikibase Suite extension now, and ship:

1. Version/build provenance display both on the Special:Version page as well as on a new Special:WikibaseSuite page (the extension)
2. Publishing of a `/wbs-versions.json` static endpoint
3. Optionally add the Announce (callback) feature to the extension screen underneath the version reporting

---

**2026-02-06 - Notes from Leif meeting:**

- Will proceed with the PRD and my recommendation as explained above: We will use an extension, and will add the Announce feature. The analytics permissioning will not be addressed in this release.
- Leif will get me copy for the Announce section and button, or we'll discuss more. Roughly speaking here are the options as well as my recommendation for minimal this first release:
- We can indicate that the Wikibase was theoretically already announced based on the value of `METADATA_CALLBACK`, but there is some chance that the callback didn't succeed and disabling the Announce button would bar the user from making sure it gets registered.
- Given this we may want to keep the Announce button still active until we have a clear and reliable way to confirm that the Wikibase was in fact already announced.
- Alternatively, we could simply indicate whether the Wikibase is currently registered in Wikibase Metadata but without implying that the user necessarily initiated this entry?
- My recommendation is to keep the button simple and dumb, always active, but also have an indicator with a brief description as to whether `METADATA_CALLBACK` is set to true or false and some brief description of this (e.g. this means your Wikibase is likely already registered).

---

**2026-02-07 - Re. Tom and Adam's responses on the Phab ticket (https://phabricator.wikimedia.org/T411587#11593626):**

- I do think we have a clear enough case to introduce a Wikibase Suite extension that is encapsulated in our Wikibase docker image distribution, which gives us:
- A place for the user to choose to Announce/Register their Wikibase with the Wikibase Metadata project if they did not opt-in with METADATA_CALLBACK on initial installation.
- Providing a "home page" for more context and resources (docs, etc) regarding the Wikibase Suite distribution itself, which the user is implictely running if this extension exists. This extension is encapsulated entirely in the Wikibase image and is not intended for distribution or use outside of that context.
- A place to hook into Wikibase code (either js or php, or both) for some liklely upcoming optional analytics reporting.
- As both Tom and Adam have now nudged this direction I will look a bit more into the `APIQuerySiteInfoGeneralInfo` action query endpoint as a possible addional place to publish versions (https://www.mediawiki.org/wiki/Manual:Hooks/APIQuerySiteInfoGeneralInfo and https://www.mediawiki.org/wiki/Special:ApiSandbox#action=query&format=json&meta=siteinfo&formatversion=2&siprop=general).
- I think we should keep the `/wbs-versions.json` endpoint as it should remain accessible even when the MediaWiki + Wikibase instance is not booting for some reason, which could be quite helpful in diagnostics in those cases.