Update libphonenumber-csharp 8.13.34

[hishamco]

https://www.nuget.org/packages/libphonenumber-csharp/8.13.34

[github-actions]

This pull request has merge conflicts. Please resolve those before requesting a review.

[Piedone]

Did you test phone number validation with the new version?

[MikeAlhayek]

@hishamco why do we need a test case to validate an external library here? Part of the adopted library has it's own testing and we should not need to add a testing on the top of their testing.

[Piedone]

I didn't mean that you should write a test. Rather, I'm asking whether you tested the phone number validation feature where it's used, like the user editor on the admin.

[hishamco]

@hishamco why do we need a test case to validate an external library here? Part of the adopted library has it's own testing and we should not need to add a testing on the top of their testing.

Mike, I thought Zoltan wanted a unit test

I'm asking whether you tested the phone number validation feature where it's used, like the user editor on the admin.

I didn't because there's no major change in the library

[MikeAlhayek]

Mike, I thought Zoltan wanted a unit test

I would remove it. Check out the last comment from Zoltan #15669 (comment)

[hishamco]

Check out the last comment from Zoltan #15669 (comment)

I already replied :)

[Piedone]

I'm just stating the obvious, but you should always test your code changes by running them, even if the change seems trivial, and especially if it's somewhat opaque like a dependency update. The reviewer has to test the changes, too.

[hishamco]

The reviewer has to test the changes, too.

Frankly I never saw this previously in the packages update, unless it's a major release coz it might have a breaking changes

[Piedone]

Every release can have breaking changes. We've seen breaking changes in .NET patch releases even. That it's not supposed to have them is no guarantee. So, naturally, you have to test the update. Flipping the version number in two files is not enough.

[hishamco]

We've seen breaking changes in .NET patch releases even

You can blame them :) especially if they are using Semver

Flipping the version number in two files is not enough.

This is too much, coz you don't know what you want to test

[Piedone]

That's part of the task: You need to check what's the impact of your change.

[hishamco]

So I will leave updating the packages, I don't think @agriffard did that for every update in the past. It would be tedious

[Piedone]

Well, is it really controversial that you have to test your changes? If a library update breaks something, what routinely happens (I personally found this on multiple occasions while reviewing, and thus also testing, PRs in OC), who has to discover that and fix it?

Keeping dependencies up-to-date is a valuable task. However, simply updating the version numbers is something that a script can do. The value lies in a human also determining that the change is safe. (And well, we could also have further automated testing, but human verification will still be necessary.)