Page MenuHomePhabricator

Stop using an older release of SMW and get back to tracking their master branch
Closed, DeclinedPublic

Event Timeline

greg raised the priority of this task from to Medium.
greg updated the task description. (Show Details)
greg added a project:
greg changed Security from none to None.
greg added subscribers: Unknown Object (MLST), scfc, greg and 7 others.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Other than not having a convenient place to test this, I think the main blocker is creating a distribution of SMW that bundles the required libraries and extensions in such a way that we can deploy it with scap. SMW uses Composer to manage dependencies and generally expects that extensions will be managed with Composer as well. For Wikimedia cluster deployment I think we will need to create something similar to the rWDBR wikidata-build-resources repo and use it to prepare a "cooked" version of SMW and the needed extensions.

Please, not another build, that would be the 4th composer run that doesn't know about all the others, which means it won't notice any incompatibilities.

T105638 is not fully a blocker for this. One could put all the SMW extensions composer dependencies into vendor by building vendor from core and extensions via composer-merge-plugin , then manually review them.

The work in progress patch to add some SMW roles to MediaWiki-Vagrant has shown that there are a variety of challenges with using the master versions of some SMW extensions when Composer isn't being used to manage the entire wiki --