I support this request from WMDE's side.
Thu, Nov 30
- For the API client to know if the Wikibase instance provides the same REST API functionality as another instance, it would be sufficient to know what Wikibase REST API schema version (OpenAPI document version) the instance provides.
- We will use the version of the schema document to reflect non-breaking and breaking changes accordingly.
- Ideally, each Wikibase instance will provide its schema (Open API document) available for clients. We’ll explore how to do it exactly, ideally in a way that does not rely on deploying Wikibase changes in particular way, but rather have API provide it itself
- We’ve decided to not indicate the schema version in HTTP response headers for now
- We see no need for now to expose the particular API implementation version (e.g. the more performant implementation of the same API functionality)
Tue, Nov 28
Fri, Nov 17
Thu, Nov 16
Thu, Nov 9
Tue, Nov 7
Thanks for the update and adjustment @Jdlrobson
I am likely missing to complete context but I think I am with @Tgr on suggesting to possibly considering some slightly different approach.
If the test is meant to be detecting significant changes in JS/CSS for WMF wikis, wouldn't it be more accurate to have tests - maybe even voting/blocking ones - that would run with the exact set of extensions and all as is provided on Wikipedia and so on? Possibly might be several "flavours" of such a check, as, as you notice, Wikidata runs a bit more code incl. JS/CSS for it custom UI, possibly similar situation could happen for Wikimedia Commons.
I don't know where such checks would live ideally in WMF Jenkins CI but having them as per-commit tests run on essentially any MW extension does seem like you might be tracking something slightly different that you actually intend to observe?
We've unblocked ourselves by skipping the test again. Apologies for the inconvenience.
Reopening as I am afraid it might be still happening. See eg. gate-and-submit jobs failing for https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/971918 -- we're quite convinced this change cannot affect Resource Loader's module size.
Nov 3 2023
Oct 30 2023
yes, thanks! I guess the only thing to "document" would be stating the API will be doing non-breaking changes whenever possible since considered stable. ("v1")
The mentioned tickets deal with the relevant details, this one is no longer needed.
Oct 29 2023
@Physikerwelt if I see correctly in https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php81-docker/13968/console, the failed end to end test was not Wikibase REST API's but mediawiki one
Oct 26 2023
Oct 25 2023
Oct 24 2023
Oct 16 2023
Keeping the ticket open for the final verification by @Ifrahkhanyaree_WMDE
Works as expected, thank you
Leaving the ticket open for @Ifrahkhanyaree_WMDE final verification.
Looks good, thank you!
Oct 13 2023
Oct 11 2023
Oct 4 2023
Oct 3 2023
@Ifrahkhanyaree_WMDE Wikibase does not validate the script used in labels/descriptions/aliases. There might be cases when that wouldn't be desired. And while it would make sense in some obvious cases it might not be a trivial mechanism to create. In any case, adding this kind of validation is something outside of API's responsibilities, i.e. it should be a policy/restriction/safety that Wikibase generally employs.
Sep 28 2023
Sep 27 2023
Sep 15 2023
oh, thanks. I stupidly checked on Wikidata not Commons.
Seems to have been potentially fixed meanwhile
Sep 13 2023
Sep 7 2023
Seems like it has been cleaned up sufficiently.
Sep 1 2023
Aug 31 2023
Aug 25 2023
Aug 24 2023