Great question! WordPress's use of Trac and SVN is rooted in history and practicality, though it creates an interesting split with Gutenberg's GitHub-first approach. Here's the full picture:
WordPress has been using Trac since at least 2004 and Subversion (SVN) as its version control system since early in the project's history. These tools were industry standards when WordPress adopted them, and Trac was specifically designed to integrate tightly with SVN.
WordPress treats SVN differently than most modern projects treat Git:
- Every commit triggers rebuilds of all plugin/theme zip files for all versions
- It's designed as a canonical release system rather than a development workflow
- This architecture supports WordPress's massive ecosystem of plugins and themes
As stated in 2020 and still true today: "This is not a signal of any decision to start moving WordPress to Git, GitHub, or GitLab. That is something that is still being explored separately... There is no further update on that at this time."
Contributors have adapted workflows that bridge both systems:
- Develop locally using Git
- Submit patches or link GitHub PRs to Trac tickets
- Committers review in Trac
- Final commits go through SVN
As one core contributor noted in 2024: "Once I tried this approach... it was a game changer in ease of use. Honestly, at this point I don't mind it at all anymore that WordPress Core uses SVN."
Migrating 20+ years of history, workflows, and tooling carries significant risk with unclear benefits. The WordPress project is incredibly conservative with infrastructure changes.
Gutenberg (the block editor) lives entirely on GitHub and uses a more modern workflow:
- GitHub Issues for bug tracking
- GitHub PRs for contributions
- Faster release cycles (every 2 weeks)
- More flexible processes
This has created two parallel contribution workflows that the community has been working to align since at least 2023:
Key challenges identified:
- Different locations: Trac/SVN vs GitHub
- Different velocities: Gutenberg releases every 2 weeks; Core every ~4 months
- Different processes: Gutenberg is more loose; Core is more formal
- Philosophy: "Gutenberg is Core, and Core is Gutenberg... Where that work occurs is not important"
Trac:
- Bug tracking and feature requests
- Release management
- Code review discussions
- Source of truth for all WordPress Core decisions
SVN:
- Canonical code repository
- Plugin/theme distribution
- Release artifacts
- Final commit destination
GitHub (wordpress-develop):
- Mirror of SVN for Git workflows
- PR-based code review (linked to Trac)
- Modern contributor experience
- CI/CD integration
WordPress now allows linking GitHub PRs to Trac tickets:
- PRs opened against wordpress-develop
- Must be linked to a Trac ticket to be considered
- Discussion still happens in Trac
- PRs are not monitored independently
- Committers still push final changes via SVN
- "If it ain't broke..." - The current system works for core maintainers
- Ecosystem scale - WordPress.org hosts 60,000+ plugins using SVN
- Committer preferences - Long-time contributors are comfortable with Trac/SVN
- Migration complexity - Moving 20+ years of tickets and history is daunting
- Community governance - Major infrastructure changes require broad consensus
There's no indication WordPress will fully migrate to GitHub/Git anytime soon. The more likely path is continued integration between the systems, making it easier to contribute via GitHub while keeping Trac/SVN as the canonical source.
The community continues to work on aligning processes between Core (Trac) and Gutenberg (GitHub) rather than forcing everything into one system.
Bottom line: WordPress uses Trac and SVN because they've used them for 20 years, they work for the project's unique needs (especially plugin/theme distribution), and the risk/benefit calculation for migration doesn't justify the massive effort required.
- Community Summit Discussion Notes: Aligning processes and contributions between WordPress Core and Gutenberg
- Working on Trac Tickets Using GitHub Pull Requests
- Providing more clarity in the Gutenberg GitHub Repo
- Aligning Committer-Level Access Across the Code Base
- The Code Repository (SVN)
- Using Subversion – Plugin Handbook
- My WordPress Core Contribution Workflow
- GitHub Pull Requests for Code Review