Page MenuHomePhabricator

Wikidata vendor version updates (Feb 2019)
Open, Stalled, NormalPublic

Description

From composer outdated, 5 of the results are wikidata related

data-values/data-values               1.1.1   2.1.1    Defines the DataValue interface and some trivial implementations
data-values/geo                       3.0.1   4.1.0    Geographical value objects, parsers and formatters
data-values/serialization             1.2.2   1.2.3    Serializers and deserializers for DataValue implementations
diff/diff                             2.3.0   3.2.0    Small standalone library for representing differences between data structures, computing such differences, and applying th...
wikibase/data-model-services          3.12.0  3.13.0   Services around the Wikibase DataModel

https://packagist.org/packages/wikibase/data-model-services#3.12.0 is also blocking updating wikimedia/assert to 0.4.0 too

I see in Wikibase/composer.json we have:

  • "wikibase/data-model-services": "^3.10.0",, so we can do 3.13.0 matching the version constraints
  • "data-values/data-values": "^2.0.0|^1.0.0", so we can do 2.1.1 matching the version constraints
  • "data-values/serialization": "^1.2.1", so we can do 1.2.3 matching the version constraint

The two conflicting are

  • "diff/diff": "^2.3.0", - We can't bump to 3.0.0 until we drop HHVM on prod (due to php >= 7.0)
  • "data-values/geo": "^3.0.1|^2.1.2", - We can't bump to 3.0.0 until we drop HHVM on prod (due to php >= 7.0)

As such.. Are we able to upgrade these first three, and then do the other two after T176370: Migrate to PHP 7 in WMF production is complete (and diff/diff is bumped in Wikibase's composer.json)?

Event Timeline

Reedy created this task.Feb 12 2019, 1:05 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 12 2019, 1:05 AM

I see in Wikibase/composer.json we have:

  • "wikibase/data-model-services": "^3.10.0",, so we can do 3.13.0 matching the version constraints
  • "data-values/data-values": "^2.0.0|^1.0.0", so we can do 2.1.1 matching the version constraints
  • "data-values/serialization": "^1.2.1", so we can do 1.2.3 matching the version constraint

This also needs to be checked with all other extensions.
I wrote a crappy script to do this some time ago, https://gerrit.wikimedia.org/r/#/c/mediawiki/vendor/+/460287/

The result right now is:

> composer-lock-diff --from ./../mw/composer.lock --to ./../current-composer.lock | grep -v "| REMOVED" | grep -v "| NEW" | sed 's/From/Master/g' | sed 's/To/Vendor/g'
+---------------------------------------+---------+---------+---------------------------------------------------------------------------+
| Production Changes                    | Master    | Vendor      | Compare                                                                   |
+---------------------------------------+---------+---------+---------------------------------------------------------------------------+
| data-values/data-values               | 2.1.1   | 1.1.1   | https://github.com/DataValues/DataValues/compare/2.1.1...1.1.1            |
| data-values/serialization             | 1.2.3   | 1.2.2   | https://github.com/DataValues/Serialization/compare/1.2.3...1.2.2         |
| guzzlehttp/psr7                       | 1.5.2   | 1.5.0   | https://github.com/guzzle/psr7/compare/1.5.2...1.5.0                      |
| wikibase/data-model-services          | 3.13.0  | 3.12.0  | https://github.com/wmde/WikibaseDataModelServices/compare/3.13.0...3.12.0 |
+---------------------------------------+---------+---------+---------------------------------------------------------------------------+

Tickets created for the ones we can action now.

"diff/diff": "^2.3.0", - We can't bump to 3.0.0 until we drop HHVM on prod (due to php >= 7.0)
"data-values/geo": "^3.0.1|^2.1.2", - We can't bump to 3.0.0 until we drop HHVM on prod (due to php >= 7.0)

Have been left for now and are blocked by T176370

Addshore triaged this task as Normal priority.Feb 19 2019, 10:23 AM

I see in Wikibase/composer.json we have:

  • "wikibase/data-model-services": "^3.10.0",, so we can do 3.13.0 matching the version constraints
  • "data-values/data-values": "^2.0.0|^1.0.0", so we can do 2.1.1 matching the version constraints
  • "data-values/serialization": "^1.2.1", so we can do 1.2.3 matching the version constraint

This also needs to be checked with all other extensions.
I wrote a crappy script to do this some time ago, https://gerrit.wikimedia.org/r/#/c/mediawiki/vendor/+/460287/
The result right now is:

> composer-lock-diff --from ./../mw/composer.lock --to ./../current-composer.lock | grep -v "| REMOVED" | grep -v "| NEW" | sed 's/From/Master/g' | sed 's/To/Vendor/g'
+---------------------------------------+---------+---------+---------------------------------------------------------------------------+
| Production Changes                    | Master    | Vendor      | Compare                                                                   |
+---------------------------------------+---------+---------+---------------------------------------------------------------------------+
| data-values/data-values               | 2.1.1   | 1.1.1   | https://github.com/DataValues/DataValues/compare/2.1.1...1.1.1            |
| data-values/serialization             | 1.2.3   | 1.2.2   | https://github.com/DataValues/Serialization/compare/1.2.3...1.2.2         |
| guzzlehttp/psr7                       | 1.5.2   | 1.5.0   | https://github.com/guzzle/psr7/compare/1.5.2...1.5.0                      |
| wikibase/data-model-services          | 3.13.0  | 3.12.0  | https://github.com/wmde/WikibaseDataModelServices/compare/3.13.0...3.12.0 |
+---------------------------------------+---------+---------+---------------------------------------------------------------------------+

So basically what I said :p

So basically what I said :p

If "composer outdated" https://getcomposer.org/doc/03-cli.md#outdated will just return the package updates.
The crappy script linked actually checks if the updates are compatible with the collection of extensions that we have installed that also define compatibility with composer packages.
If we blindly trust the outdated command then we will end up occasionally updating packages before all of our extensions are actually ready for the update, likely breaking things.

This time they happened to be the same, but I still wanted to document my process for future linkability and searchability etc (and to show you)

Reedy added a comment.Feb 20 2019, 9:45 AM

So basically what I said :p

If "composer outdated" https://getcomposer.org/doc/03-cli.md#outdated will just return the package updates.
The crappy script linked actually checks if the updates are compatible with the collection of extensions that we have installed that also define compatibility with composer packages.
If we blindly trust the outdated command then we will end up occasionally updating packages before all of our extensions are actually ready for the update, likely breaking things.
This time they happened to be the same, but I still wanted to document my process for future linkability and searchability etc (and to show you)

I know. Which is why I looked more manually at the composer.json, and how/why I said not now for
Some. But the answer is still the same

All subtasks are resolved. Can this be closed?

Reedy changed the task status from Open to Stalled.Mar 3 2019, 2:11 PM

All subtasks are resolved. Can this be closed?

Nope. @Addshore only created tasks for the immediately actionable items. The other two are basically blocked on T176370. Setting to stalled for now

Addshore renamed this task from Wikidata vendor versions updates (Feb 2019) to Wikidata vendor version updates (Feb 2019).Jun 14 2019, 2:50 PM