HHVM is known for its very intense and quick development pace: currently we ship to GitHub the exact same code we use to run the Facebook site within minutes of every commit, and we release a full version every 8 weeks. That is great and at the same time scary if you are trying to build a business or infrastructure around it.

The HHVM team at Facebook understands that in order to reach every corner of the PHP landscape our users need to have some sort of commitment, in order to plan their deployments accordingly and to know how upstream will react to security and stability fixes in already released versions, for example.

The deal

For these and other reasons, starting with HHVM 3.3, the HHVM team will support two source releases at all times (that we will call LTS, Long-Term Support), separated by roughly 6 months (24 weeks apart to be exact), to have an effective support cycle of nearly a year. As an example, HHVM 3.3, which is scheduled for 11th Sept 2014, will be supported until 3.9 is released (8x6=48 weeks later, about 11 months). Accordingly, 3.6 (hopefully released 24 weeks after 3.3) will be supported for 6 releases (until 3.12 or equivalent sees the light). Confused? Let’s try a table!

Version name Intended Release Date LTS? End of support
3.3 11 Sep 2014 yes 13 Aug 2015
3.4* 6 Nov 2014 no  
3.5* 1 Jan 2015 no  
3.6* 26 Feb 2015 yes 28 Jan 2016
3.7* 23 Apr 2015 no  
3.8* 18 Jun 2015 no  
3.9* 13 Aug 2015 yes 14 Jul 2016
3.10* 8 Oct 2015 no  
3.11* 3 Dec 2015 no  
3.12* 28 Jan 2016 yes 29 Dec 2016
3.13* 24 Mar 2016 no  
3.14* 19 May 2016 no  
3.15 14 Jul 2016 yes 15 Jun 2017
* Release names uncertain, but you get the idea.

What about official distribution packages?

Additionally to the above, we are pushing really hard to get official Debian packages into the main archive, which would make their way into Debian stable, Ubuntu semiannual releases, as well as any Debian derivatives. We are aware of the long support cycles of those distributions and we intend to support whichever version is released with Debian and Ubuntu stable versions for security-related fixes for as long as that version is supported in Debian/Ubuntu.

We are trying to come up with plans for other distributions like Fedora, but our resources are limited for now and while we will keep releasing packages for many distributions, we may not cover them with LTS.  This doesn’t mean that we are not going to have the usual RPMs or DEBs for various distros in every release, but they will not be residing in official repos.

What type of updates I may expect in LTS releases?

This can easily be a hot topic for the community and at the same time become a burden for the team, so let’s be clear. The answer is it depends.

It depends on the severity of the problem we want to fix and intrusiveness of the patch to apply. Security issues? Absolutely! Big regressions? Sure, why not, if they don’t imply re-architecting a big chunk of code. Small patches that can drive that version to 100% completeness on some framework? Let’s do it. But observe that the longer an LTS release is out there, the less likely we will be doing major surgery on it. Security fixes will have absolute priority, and the rest of issues will need to be studied by balancing the amount of work patching and testing vs. the benefit and the risk of getting it out of the door. We expect you, the users, to guide us with PRs or features that you would like to have in the current LTS releases.

We are finalizing the plan and we may need to make adjustments to it. Do you have any questions or suggestions? Please comment!

Ender works in Facebook as Security Engineer and has a passion for packaging. He’s been a Debian Developer since 2001.


  • Alex Bilbie: This is great to read. What plans are there to improve the HHVM documentation? There is a lot of inconsistent or missing or out of date documentation across docs.hhvm.com and the Github wiki especially around server configuration.
  • Graham Campbell: Will there be nightly packages for the lts branches?
  • Paul Tarjan: No concrete plans from us. Please open github issues and we'll tag them with documentation. The docs are in github so send us PRs to fix any problems you see, and the wiki is, well, a wiki. So please edit it as you see fit. If you don't know how open an issue or ask us on IRC.
  • Paul Tarjan: I wasn't planning on it. I don't think diffs will live on the branch very long before a release is made as they will mostly be security fixes which shouldn't live in the open for long.
  • Christopher Pitt: "Mac OS X installation is currently EXPERIMENTAL and UNSUPPORTED."
  • Ender: As Paul said, the LTS are mostly designed to be released as point releases, similar to what a stable Linux kernel is nowadays. With that in mind, it's likely to have maybe release candidates for the first releases if we have more stuff than can be comfortable, but otherwise it wouldn't make sense to have continuous builds on those.
  • Xandi Ostermeyr: great to read. should make it significant easier, to setup a hhvm environment in a company. but like alex said, it would be great if you could provide also "versioned" documentation for the LTS releases.
  • Ender: Hum. That is a very interesting point, thanks for bringing it up. Do you think it makes more sense to have something by release, as e.g. MySQL (which I find particularly overkill for HHVM if you ask me) or adding version information to the documentation (similar to e.g. jQuery: https://api.jquery.com/ajaxSuccess/). I'd like to hear any arguments towards or against it.
  • Ender: What do you mean with your comment? It would be great to hear a constructive explanation instead of a rant. :-)
  • Ender: Given that I got 0 comments, my decision is that we will go with the jQuery model from now on. I'll spread the word around that we need to add version information to the documentation.
  • netroby: Your lts not really lts , Ubuntu LTS will continue several years. You just support for several month. It's not really good for who want stable .
  • Aftab Naveed: We are using hhvm 3.3 in our production, performance has been great so for, but the question is all the future version will carry compatibility of code ? or code adjustments might be required.
  • Fred Emmott: Any future 3.3 release should be compatible with code that worked on 3.3.0 and any other current 3.3 release. Outside of the same release series, we've generally been following what PHP5 does - this is usually deprecation warnings before something breaks. We've not yet decided how we're going to handle the breaking changes in PHP7.
  • harshit: great to see this...is HHVM now available on fedora? would be great if it is.
  • dipen: HHVM latest or after 3.9 for centos 6 64bits please ?
  • Josh Watzman: We unfortunately only have the resources right now to maintain Debian and Ubuntu packages. There are community-contributed directions here, which may or may not work, and aren't supported by the team: https://github.com/facebook/hhvm/wiki/Building-and-installing-HHVM-on-CentOS-6.6
  • Josh Watzman: We unfortunately only have the resources right now to maintain Debian and Ubuntu packages. There are community-contributed directions here, which may or may not work, and aren't supported by the team: https://github.com/facebook/hhvm/wiki/Building-and-installing-HHVM-on-Fedora-19-or-20