Update .travis.yml to use Precise/Xenial distributions

[sanmai]

More info: https://docs.travis-ci.com/user/languages/php/#choosing-php-versions-to-test-against

[GrahamCampbell]

Probably only the 5.3 build should be run on the old infrastructure. See https://github.com/schmittjoh/php-option/blob/1.5.3/.travis.yml for an example of how to do this.

[sanmai]

I don't think it makes a big difference, since we're only using PHP during testing, and it is all same here and there, but here you go anyway.

[GrahamCampbell]

Could you update HHVM to match the example config file I posted too, since currently it's not even running the tests at all. Either we should run on HHVM 3.x, or delete HHVM from the travis config.

[sanmai]

I've made the tests pass under HHVM, but seems like we're using a native implementation under the version of HHVM you have proposed that we use. Shall we use a different versions, or just remove it altogether? What do you think?

[GrahamCampbell]

Hmm, maybe?

[GrahamCampbell]

Or use an older version of HHVM?

[sanmai]

Any suggestions?

[sanmai]

Evidence suggests that the password_hash functionality was available in HHVM at least since 2013, or from HHVM-2.4.0. Version right before that is HHVM-2.3.3.

[GrahamCampbell]

meh, i mean, why do we even need to keep testing this library. php 5 is not changing, ever.

[sanmai]

It isn't abandoned yet, is it?

[sanmai]

FWIW apparently there's no HHVM-2.3.x on Travis.

[sanmai]

OK, build is green. If you, or anyone, could squash-merge this, thank you very much.

[GrahamCampbell]

It isn't abandoned yet, is it?

Well, no, but it's also "finished".

[ircmaxell]

Consider it End of Life. The last version of PHP for which this library does anything is 5.4, which stopped receiving security updates in September of 2015.

I recognize that a non-trivial number of people still use 5.3 and 5.4 in production, which is why this project isn't abandoned, but there's just no new work left to do. Short of a non-trivial bug being found (which hasn't happened in years), I don't anticipate any further releases.

[sanmai]

Understood. This isn't a change that should lead to a release, but rather developer QOL improvement. Given a bug is found, or composer changes its scheme, or just about any PR, with this change you would immediately see that there's something wrong from a failure during CI. Because that's what this change is about: fixing the CI.

Without this change a simple README.md correction may cause a build failure to be reported everywhere for this project.

[ircmaxell]

Oh, I'm definitely not against things like this. Just providing some context as to the expected velocity of the project...