Symfony

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. ...

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. ...