TrinityCore in three branches, and where its README stops

Three branches, three client builds, three CI vendors

TrinityCore is an MMORPG server framework based mostly in C++ and derived from MaNGOS, the Massive Network Game Object Server, which the README describes as the code base it grew from, changed over time to optimize, improve and clean up the codebase while improving in-game mechanics. The repository description carries the map that decides everything else: master tracks client build 12.1.0.69875, the 3.3.5 branch tracks 3.3.5a.12340, and cata_classic tracks 4.4.2.60895.

The build status table follows the same three names. Each is built on CircleCI, on AppVeyor, and on GitHub Actions, where the workflows are labelled Windows x64, Ubuntu x64 and macOS arm64, and the cata_classic column shows a GCC workflow in place of the Windows x64 and Ubuntu x64 ones while keeping macOS arm64. Choosing a branch means choosing a client build and a set of build jobs at the same time, and the README does not tell a new operator which one to take.

TDB tags are database releases, not code releases

The three most recent releases are not source builds. They are TDB335.26091 from 2026-09-09, TDB1210.26091 from 2026-09-09 and TDB442.26081 from 2026-08-14, and each name carries a branch number inside it, one per branch line.

The structure says something the README never spells out: for this project, server code and world data are versioned on separate tracks, and an operator needs both. It also means the visible release history holds no code version at all, so it tells you nothing about which source revision a running server came from. No page in the README explains how to apply a TDB, where to download one, or whether it must match your branch exactly. Treat the tag names as evidence that the database has its own upgrade cycle and go looking for that procedure in the wiki before you assume a pull of master is enough.

No build command anywhere in the README

Expect to be sent elsewhere before you compile anything. Software requirements for Windows, Linux and macOS live at trinitycore.info/en/install/requirements, and the detailed installation guides live at trinitycore.info/en/home. Not a single configure or build command appears in the README itself.

The tree shows what the build is assembled from. The top level carries CMakeLists.txt, a cmake/ directory, PreLoad.cmake, revision_data.h.in.cmake and appveyor.yml, next to src/, sql/, tests/, contrib/ and dep/, plus an INSTALL file and a doc/ directory. So the project is CMake driven, keeps SQL inside the same repository, and has a tests/ tree, yet the exact toolchain, compiler versions and database setup steps are all wiki content. There is nothing here to copy and paste, which makes the wiki the real installation documentation for anyone starting from a fresh clone.

C++ fixes travel as pull requests, SQL fixes as tickets

The contribution model splits by language. C++ fixes are submitted as pull requests against the GitHub repository, and the README links a guide on maintaining a remote fork for that purpose. SQL-only fixes take a different road: open a ticket, and when a bug report already exists for that bug, post on the existing ticket instead of filing a new one.

That split has consequences for anyone sending patches. A database fix cannot be expressed in the pull request flow described in the README, so it depends on tracker access and on a maintainer applying it. The repository itself reflects the split in its templates: issue_template.md and pull_request_template.md sit at the top level next to CONTRIBUTING.md, and the README does not summarise what any of the three asks a reporter to fill in. Read the templates before writing either, because the tracker and the pull request are different doors.

Poorly formed issue reports are deleted outright

Issues go to the GitHub issue tracker, filtered by the Branch-master label on the master branch. Before filing one, the README asks you to review existing issues to prevent duplicates and to read the issue tracker guide in full so your report carries the required information. It then states the consequence without softening it: incorrect or poorly formed reports are wasteful and are subject to deletion.

For users this makes the tracker a place to file a complete report rather than a thought. A report missing what the guide asks for can be removed, and the Branch-master label is a reminder that a report belongs to a specific client build, so a classic branch bug filed against master is filed in the wrong queue. Two isitmaintained.com badges sit at the top of the README, one for average time to resolve an issue and one for the share of issues still open. The guide that decides whether a report survives lives on the community forums, one hop outside the code.

The documented fork walkthrough assumes TortoiseGit

Pull requests need a fork, and the walkthrough the README links is titled how to maintain a remote fork for pull requests, TortoiseGit. The subject is the point. The project's own contributor documentation is written around a Windows graphical Git client, which is also the platform the Windows x64 workflow builds.

Contributors on Linux and macOS, the two other platforms named in the requirements and install links, get no equivalent procedure from this repository. GitHub accepts a pull request from any client, but the fork, branch and sync steps that turn a local change into something reviewable are described only for TortoiseGit. Budget time to read the forum topic and translate it into command line git, or ask in the Discord channel linked at the bottom of the README.

Coverity and three CI vendors sit over master and 3.3.5

Static analysis is part of the build status rather than beside it. The table links two Coverity scans, projects 435 and 4656, in the master and 3.3.5 columns, and above them sit CircleCI badges, AppVeyor badges and GitHub Actions links that open one workflow and one branch directly.

Two details are worth reading closely. The AppVeyor badge points at a project under the DDuarte account rather than under the TrinityCore organisation, so that column's history lives outside the organisation's own infrastructure. And the cata_classic column shows a GCC workflow where master and 3.3.5 show Windows x64 and Ubuntu x64, while all three keep macOS arm64, which means the classic branch is built under a different toolchain from the other two, a choice the README does not explain. There is no single build to watch across branches: a red badge only means something once you know which branch your server runs.

No download, module or bot support is described here

A good deal of what people ask this project for is outside its documentation. There is no download section, no module list and no bot support described in the README, and the four links at the bottom are the project's own channels: trinitycore.org, the wiki at trinitycore.info, the forums at talk.trinitycore.org and a Discord server.

The tree does carry contrib/ and sql/ directories, and the README names neither. Treat that as a boundary rather than a gap to guess around: the README gives no detail about what those directories contain. If your plan depends on a module, a bot or a client download, confirm it in the wiki and on the forums before budgeting for it, because nothing in this repository will tell you what is supported.

Editorial conclusion

TrinityCore fits an operator who has already decided which client build the server will run and is willing to follow trinitycore.info for the toolchain, because the README carries no build command and no database steps. It does not fit someone who needs a single documented setup path on every platform, or a contributor who cannot reach the forums and Discord where the fork walkthrough and the issue rules live. Before you clone, settle three things: whether master, 3.3.5 or cata_classic is your target, which wiki page covers your platform's requirements, and how the TDB tag for that branch gets applied. The last push to the repository landed on 2026-11-02.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. TrinityCore/TrinityCore on GitHub