Test with libyaml 0.2.4

[perlpunk]

libyaml 0.2.2 tests are currently failing:
https://travis-ci.org/github/yaml/pyyaml/jobs/689453153#L1145

Maybe because the wrong testsuite commit gets checked out.

Edit: .appveyor.yml should also be updated

Edit: I fixed the libyaml tests with this: yaml/libyaml@a718a89

If you plan a 5.3.2 bugfix release, this PR should be merged after that.

[bsolomon1124]

@perlpunk for 5.3.1, was 0.2.2 the libyaml version tested against prior to that release or was it an earlier libyaml version?

Secondly, I'm curious if PyYAML has any sort of policy for when/under what circumstances/how often it bumps the libyaml version against which it tests? Asking partly for #407.

[perlpunk]

or 5.3.1, was 0.2.2 the libyaml version tested against prior to that release or was it an earlier libyaml version?

5.3.1 was tested against libyaml 0.2.2.
But there was a bug in the libyaml testsuite code, which is very complicated, which resulted in checking out the wrong version of the test data, that's why we got the errors in travis.
It's fixed now, but I hope we can get rid of that fragile code at some point: yaml/libyaml#171

Secondly, I'm curious if PyYAML has any sort of policy for when/under what circumstances/how often it bumps the libyaml version against which it tests?

In general, I would say, bugfix releases (like 5.3.2) should always be built with the same libyaml version.
Otherwise, the libyaml version should be updated whenever possible, I would say, but @ingydotnet is the one who decides what gets in a release.
The goal is also to try and keep libyaml & PyYAML behaviour in sync, so if a bugfix happens in libyaml that allows parsing something which was not accepted before, that bug should also be fixed in PyYAML.

[bsolomon1124]

If you plan a 5.3.2 bugfix release, this PR should be merged after that.

Okay, so if I'm reading this correctly, the plan would be for 5.3.2 to keep things at 0.2.2 libyaml upstream, but possibly to upgrade (for both tests and potentially wheels) in some release after that.

For #407, I have it at 0.2.4 for now, but that can easily be changed to 0.2.2.

And the last thing I'd note is, if the libyaml version is going to be referenced multiple places here, it might make sense to keep it in a single place (maybe a LIBYAML_VERSION file or something). I'll resist the the urge to suggest adding libyaml as a Git submodule 😉

[perlpunk]

libyaml 0.2.5 is in the 5.4 release, closing