PHP 7.2 released November 30th. The headline isn’t a language feature, it’s a removal. mcrypt is gone. This is good news, even if it doesn’t feel that way when you’re the one migrating. The mcrypt problem mcrypt has been unmaintained since 2007. More than a decade of stagnation in a cryptography library. It was deprecated in 7.1, and 7.2 removes it entirely. The replacement is sodium, now bundled as a core extension. ...
Symfony 4.0 released November 30, 2017, same day as 3.4. The shared release date is pretty much the only thing they have in common. 4.0 is a different philosophy. The Symfony Standard Edition, the monolithic starting point that bundled everything and left you to remove what you didn’t need, is gone. In its place: a microframework that grows. Flex Symfony Flex is a Composer plugin that changes how you install Symfony packages. Before Flex, adding a bundle meant: install via Composer, register in AppKernel.php, add config to config/, update routing if needed. Four steps, all manual. ...
Symfony 3.4 and 4.0 were released the same day: November 30, 2017. That’s not a coincidence, it’s the strategy. 3.4 is not a feature release. It ships with exactly the same features as 3.3, plus every deprecation warning that 4.0 will enforce. Its whole purpose is to be the migration tool: upgrade from 3.3 to 3.4, fix what’s in your logs, then step to 4.0 cleanly. Why LTS releases matter in Symfony’s model Symfony releases a new minor version every six months. That pace would be brutal for production apps to follow, so the project designates every fourth minor as an LTS: three years of bug fixes, four of security fixes. Which means teams can target 3.4 and mostly stop thinking about upgrades for a while. ...
Symfony 3.3 shipped May 29th. It’s the release that changed how I think about service configuration. In hindsight, it was basically a preview of what 4.0 would make the new default. The autowiring problem Before 3.3, Symfony’s DI was powerful but verbose. Every service had to be declared explicitly in services.yml with its arguments listed. Autowiring existed since 3.1, but it was opt-in per service and had enough edge cases to bite you. Teams either wrote mountains of YAML or leaned on third-party bundles to cut the noise. ...
The rule was simple: whoever breaks the CI build owes the team a coffee. It worked fine for a while. Then someone suggested we needed something with more immediate feedback. Something physical. Something that fires. A Dream Cheeky Thunder appeared on a desk shortly after. Four foam missiles, a USB cable, and a very clear team consensus: hook it to the cluster, wire it to the build pipeline, and let the CI decide who deserves a volley. ...
A timestamp coming back from the database one hour off. Not every time. Only when the dev server runs in Europe/Paris and CI runs in UTC. The kind of bug that disappears when you look for it and comes back in production on a Friday evening. The problem isn’t in the business logic. It’s in what Doctrine quietly does with dates. What Doctrine does by default When you declare a datetime field in a Doctrine entity, the conversion between PHP and the database goes through DateTimeType. That class calls format() on your DateTime object to write to the database, and DateTime::createFromFormat() to read it back. No mention of timezone anywhere. ...
PHP 7.1 shipped December 1st. No 2x performance headline, no engine rewrite. It fills in the gaps that 7.0 left in the type system, and those gaps were genuinely annoying. Nullable types 7.0 let you declare string $name as a parameter type. What it didn’t let you do was say “this can also be null”. You had to drop the type hint entirely or hack around it. 7.1 adds ? prefix: ...
PHP 7.0 dropped on December 3rd. A month and a half in, I’ve migrated two projects and the results are hard to ignore. The headline number is 2x faster than PHP 5.6. That’s not a benchmark cherry-pick — it’s the median across real applications. The Zend Engine was rewritten to use a new internal value representation that cuts memory usage significantly and reduces allocations. On one project, average response time dropped by 40% with zero code changes. You just upgrade and it goes faster. ...