Kohana on PHP 7: whose problem is it

The test suite went green on the PHP 7 release candidate on the second try. I expected worse. Then I opened modules/ and the mood changed.

The core mostly works. The community is patching compatibility in the 3.3 branch on GitHub right now, and the fixes are small: deprecated PHP 4 style constructors, changed engine behavior in dark corners. Whoever says the framework is dead is not reading the commit log. It is not dead. It is volunteers.

The modules are the real problem. Our project carries a dozen third-party Kohana modules, and half of them saw their last commit around 2012. Nobody will make them PHP 7 ready. If we want them, we patch them ourselves.

Which means “does Kohana support PHP 7” is the wrong question. The right one: who supports our copy of it. And the answer quietly became “we do” some time ago. In practice we maintain a private fork of a framework plus a museum of modules attached to it.

That can still be a rational choice. Patching a small, stable framework costs a few days a year. But this cost curve only goes up: every new PHP version, every security finding, every new hire who has to learn a framework with no future. Migration cost, meanwhile, stays roughly flat.

So I keep a simple ledger now. Hours spent this quarter keeping the framework alive. When that line grows past the boring, steady estimate for a strangler-style migration, the decision makes itself. No drama. Just arithmetic.

The ledger has one weakness. I fill it in, and I like patching the framework more than I like the migration. The hours in it are probably a bit low.

For now the tests pass on the RC. We buy another year.