To see when a version of a service changes and give that in bug reports, e.g., it would be great to let RESTBase expose it's version to Special:Version. For this, RESTBase needs a stable endpoint to get it's own version, maybe the git sha2 and/or the date of this commit (like Special:Version does it for the MediaWiki version, if it's a git clone.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T108226 Special:Version should show the versions of services that a wiki uses | |||
| Declined | None | T114681 RESTBase should have a version endpoint |
Event Timeline
Comment Actions
RESTBase is a very modular framework that's largely driven by a Swagger-based config. The swagger spec documents all aspects of the APIs, and is versioned using a path-based scheme (/v1/) as well as stability markers on individual end points.
A single 'RESTBase version' in the form of a hash over all module hashes (or the entire source) wouldn't really give you much useful information. It should make a lot more sense to reference the Swagger spec and/or docs instead, as this documents all the bits clients should care about.
Example URLs:
Comment Actions
Thinking about this some more, I don't see how a sha1 or the like would be helpful unless we have a way to reproduce the state captured by that hash. At the same time, the hash would need to cover a fairly long list of dynamic configurations from puppet.
It seems a lot simpler to just provide the time in a bug report (if differing from the report timestamp). This gives us all the information we need in a reproducible fashion, including code hashes, config hashes etc.
So, I'm leaning towards declining this task. Any objections?