Since Symfony version 2, the project’s code has been managed as a Git mono-repository. Having all the code in one place is very convenient: from changes across the board to centralized issues, it makes everyone’s life much easier. Since Symfony 4, the mono-repository is only used for development and not used anymore as a Composer project dependency (symfony/symfony). Instead, projects now depend on individual packages (symfony/console, symfony/http-kernel, …). It is a great optimization as it saves some significant bandwith by not downloading code you will never use. It also allows Symfony 4 to automatically enable or disable features based on your dependencies. The mono-repository is still the single source of truth though as the individual packages are automatically updated thanks to a technique known as Git subtree splits. Whenever we create a new release, we are tagging the mono-repository and then, tags are automatically created for each individual package. But as the number of Symfony components grows, it also means that we are creating more “empty” tags. Even if a package has had no changes since the last patch release, we are still creating a new tag. It has one big advantage: you can easily spot in the composer show output if all Symfony packages are up-to-date. Creating tags when no changes occur is also wasting resources: CIs updating dependencies, developers downloading new versions even if they don’t need to, time spent waiting for the downloads, … We are wasting human resources, but also infrastructure resources. Talking about optimizing infrastructure resources, we have worked hard to optimize our CI pipelines to avoid redundant activities as much as possible. Today, we are going one step further. Starting with the next releases, we won’t create tags anymore for packages when they had no changes since the last patch release as we consider the benefits far more important than the inconvenience of not having all Symfony packages using the same patch version. It also has one side-effect: sometimes, we tag a release with a major regression in one component. Even if we fix it right away, we are always reluctant to tag a new release right away to avoid creating many new empty tags. No more. When such regressions happen, we will now be able to quickly create a new release. Besides the main Symfony repository, we will do the same for Symfony Contracts, Symfony Polyfills, and Twig. That’s maybe a baby step, but a good one nonetheless to protect our planet.
Sponsor the Symfony project.
Connectez-vous pour ajouter un commentaire
Autres messages de ce groupe

SymfonyOnline June 2025 is almost here, starting in almost 2 months on:
June 10-11: Workshop days. It is possible to attend 1 two-day training or 2 one-day trainings. June 12-13: Online confe

The Validator component provides dozens of constraints ready to use in your applications. In Symfony 7.3, we've added two new constraints to the list.
Slug Constraint

SymfonyOnline June 2025 is almost here, starting in almost 2 months on:
June 10-11: Workshop days. It is possible to attend 1 two-day training or 2 one-day trainings. June 12-13: Online confe

Contributed by Jérôme Tamarelle in

This week, we kicked off the New in Symfony 7.3 blog series, highlighting all the exciting new features coming in this release. We also unveiled more details about some of the SymfonyOnline June 2025

SymfonyOnline June 2025 is almost here, starting in almost 2 months on:
June 10-11: Workshop days. It is possible to attend 1 two-day training or 2 one-day trainings. June 12-13: Online confe

Symfony's Messenger component makes it easy to build message-driven applications. However, developers using symfony/amqp-messenger have long faced a limitation: it relies on polling (get()), which can