symfony's default branch is 8.2, and three patch lines shipped within eight minutes

Three patch lines shipped within six minutes of each other

The release list is a snapshot of a support policy in progress. Three versions were published on 2026-10-28: 6.4.49, then 7.4.22 about four minutes later, then 8.1.10 about four minutes after that. The last push to the repository was recorded on 2026-11-02. Three maintained lines, patched in the same run, is what a long term support policy looks like in practice, and the file states the rules plainly: Symfony follows semantic versioning strictly, publishes long term support versions, and has a release process it describes as predictable and business friendly. The practical consequence for a reader is that the version you run and the version you install are two different decisions. Maintenance on an older line does not stop when a new one opens, so an application can stay where it is for a long time and still receive fixes, which is the opposite trade from a project that only ships the newest line.

The default branch is named 8.2, and 8.2 is not released yet

The branch this repository serves by default is called 8.2, and the newest published release is 8.1.10. That naming is the whole version strategy in one word: branches are named after the version they are building, so a clone is not a clone of a stable line, it is a clone of the next one. The repository root confirms the same thing from the other side. There are upgrade guides for 8.0, 8.1 and 8.2, so the changes for the unreleased version are already being written up for the people who will have to apply them, while the changelog files stop at 8.0 and 8.1, so there is no record of the 8.2 changes yet. Both facts together are a reasonable signal of where the line stands: the upgrade notes are ahead of the release, which is exactly the order you want them in if you plan to upgrade rather than track.

One source tree holds the framework and the components together

The file presents the project as two things at once: a framework for web and console applications, and a set of reusable components. The repository tree shows those as a single source directory with configuration beside it, not as a set of sibling component directories, so the separation between framework and components is something the packaging does rather than something the checkout shows. The documentation section keeps the same split, with a components reference listed alongside the guides, the tutorials and the best practices reference. For a project that wants one library rather than a framework, that distinction is the whole decision, and it is not answerable from the tree. What the tree does tell you is that everything is in one repository with one composer manifest, one licence file and one set of analysis and formatting configurations, which is a coherent thing for a project that treats its components as released together.

Two static analysers, two style fixers, and no test directory in the listing

The quality tooling at the root is doubled up in a way that is deliberate rather than accidental. There is a static analysis configuration for one analyser and a configuration for another, and two code style fixer configurations, one for PHP and one for Twig templates, so template markup is held to the same standard as application code. There is a spell checker configuration, an editor configuration, and a file that tells version control which revisions to keep out of blame, which is what a repository does when it has automated formatting commits in its history. There is a PHPUnit configuration and an entry named for the PHPUnit binary, and an agent instructions directory. What is not in the listing is a top level test directory, so where the suite lives is something a contributor learns from the configuration rather than from the file list, and the front page does not mention any of these tools.

The front page is a directory, and one of its links resolves to nothing

The file is about three hundred words and almost all of it is links, which is a defensible choice for a project this size and one that ages well. It covers what the project is, that installation is with Composer, the versioning and long term support promise, a sponsorship appeal, six documentation entry points, the community and support channels, a code of conduct and a care team, a separate track for contributing documentation, a security disclosure procedure, and a line saying development is led by a core team and supported by contributors. The defect worth naming is small and specific. The sentence asking people to sponsor the development points at a reference whose definition is just the scheme with no host, and three other references ([28] to [30]) in the same list are defined the same way, with one number skipped entirely. So one of the two sponsorship links goes nowhere; the backers link still resolves.

The demo application and the book live outside this repository

The documentation section does not send a new user to a single starting page. It offers a getting started guide, a demo application, a book intended to take you through the framework properly, and then a set of longer references covering guides and tutorials, the component documentation and a best practices document. The demo application is named as its own project, and the book is a separate resource, so both are things you adopt rather than things in this checkout. Support is offered through GitHub Discussions and Slack, and the file adds a code of conduct and a named care team, which in practice is the route for conduct and welfare matters rather than for bugs. Security has its own documented procedure rather than an address, which is a deliberate choice for a disclosure channel. The README does say to read the Getting Started guide if you are new to Symfony, but the other starting points come with no suggested order.

Nothing in the tree says how the components are published separately

One file at the root is worth a reader's attention because the front page never mentions it: a configuration for a tool whose job is splitting a monorepo into other repositories. If the project publishes per component read only mirrors, the mechanics live in that file and not in the documentation, which means the relationship between what is in this repository and what you install from elsewhere is documented somewhere other than where a reader would look. There is also a file named link at the root, a git attributes file, a contributors file and a changes ignore file, and none of them are explained in the readme. This is the same pattern as the rest of the project, and it is worth naming as a pattern rather than as a defect: the repository is authoritative for code and the website is authoritative for everything a person is supposed to understand, so anyone who wants to know why a component looks the way it does is expected to read the source rather than the description.

Editorial conclusion

Adopt it if you want a framework with published long term support lines, a documented upgrade guide per minor version, and components you can take one at a time, and read the upgrade file for your target version before you move. Do not clone the default branch expecting a release, because it is the 8.2 line under development, and do not look to the front page for architecture or a component list, because it is a directory of links and one of those links, the sponsoring one, does not resolve.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. symfony/symfony on GitHub