Should we support PHP 5.4 (support officially ended in 2015) and PHP 5.5 (support officially ended in 2016)? More specifically I'm thinking about backwards compatibility "hacks" like this: 338497f I haven't seen anything like that in the current codebase.

Do the community have the need for official HHVM support? Just figured out that I don't have the time to maintain HHVM compatibility in top of the new PHP releases given the fact that PHP 7+ is very close to HHVM's performance and "HHVM will not aim to target PHP7". Currently the HHVM mysql+psql build is running just fine (and I don't have the time to figure out what's wrong with sqlite) so we can include it in the repo but I think that would be an (unnecessary) commitment.

I think we should add nightly to our build and allow it to fail. This will help us move to the next PHP versions in the future. With PHP5's deprecation later this year I think this is a very important thing to do.

What are your thoughts?
@vlucas @tuupola @nebulousGirl @willemwollebrants

ping

I feel like if we change support for PHP versions, we might have to do a major release, or at least a clear minor version bump with notes on why. I would like to do another patch version release before we do that to get out all the fixes that are in master first.

I can agree with that.

• We could support PHP<5.6 for a while as well.
• What do you think about HHVM? Should we support it or should we open in the direction of PHP7.2+ only?

HHVM has kind of fallen out of favor with PHP 7+ performance being on-par with it. I'd be okay with dropping it in the next major release if it is burdensome to maintain support for.

This blog post just came out. Let's drop HHVM for sure in the next major version.
https://hhvm.com/blog/2018/09/12/end-of-php-support-future-of-hack.html

@vlucas Travis CI is no longer working, this PR is invalid in this form. It has to be updated after #302 is possibly merged.