Krinkle added a comment.
> - `mediawiki-vendor` runs some tests (including WIkibase unit tests), as can be seen in https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/676007 > - Thus `mediawiki-vendor` changes must depend on changes to extensions such as Wikibase, as can also be seen in https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/676007 > - This means that changes to these extensions can not actually depend on the `mediawiki-vendor` change itself, as happened in this WIkibase change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/676077 > > […] I was surprised to hear this because for core we have always been able to do it the opposite way. Patches to mediawiki-vendor that check in new or changed core dependencies, have no Depends-On instruction, and their tests pass fine. On the mediawiki-core side, there is (naturally) always a Depends-On so that the core patch can pass its unit tests wit the new code (both for new code it introdues, as well as to satisy the Installer, which ensures vendor exists and matches composer.json requirements). For example change 672487 <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/672487>, and change 674386 <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/674386>. The mediawiki-vendor repo has significantly fewer tests and that's basically the trade-off we made to make these patches easier to work with. The trade-off involves two important social expectations: 1) that you never ever merge stuff here unless it's been tested with Depends-On from a +2'ed patch in core or a gated extension repository, and 2) that the update is at least backwards-compatible for one commit while this stack lands. This first point is non-obvious and has at times led to a broken CI. This second one is more obvious in terms of discovery since tests will fail if it isn't followed. For core updates this is usually unsurprising in my experience since we have a stability policy and if a lib change were to be breaking in a way that doesn't merely remove already-deprecated features, we'd have no way to upgrade anyhow since we can't atomically update callers in multiple production repos and upgrade a library all at the same time. You first prepare any callers to be forward-compat, and then just do the upgrade smooohly as a (hopefully) unnotable event. TASK DETAIL https://phabricator.wikimedia.org/T279898 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Krinkle Cc: Krinkle, WMDE-leszek, hashar, Jdforrester-WMF, Tonina_Zhelyazkova_WMDE, Tarrow, Addshore, Aklapper, Invadibot, maantietaja, Mgagat, Akuckartz, Totolinototo3, Redabr4, Zanziii, Sadisticturd, Eladio.15, DannyS712, Nandana, A.S.Kochergin, Lahi, Gq86, Daimona, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
