stan-dev/stan: the default branch is develop, so a fresh clone is one minor version ahead of the release

The default branch is develop, and a plain clone is ahead of the release

Most projects that tell you master holds the release make it their default branch. This one does not. The repository's default branch is develop, and its description says the master branch contains the current release while the develop branch contains the latest stable development, with the developer process wiki holding the details. So git clone gives you the development line, not the released one, and the gap is not trivial: the newest release is v2.40.0, published 2026-09-16, and develop has been receiving work since, with the last push on it dated 2026-09-23, a week after that tag. For a scientific library where the numerical behaviour of a sampler is the product, cloning the default branch and assuming you have the release is the first mistake available to make here.

A minor release every four months, with a candidate about a week ahead

The release titles carry their own dates in parentheses, which makes the cadence easy to read. v2.40.0 is titled with 16 September 2026 and was published that day. Its release candidate, v2.40.0-rc1, is titled 9 September 2026 and was published on 2026-09-09, so the candidate window is roughly a week. The previous minor, v2.39.0, is titled 19 May 2026, putting the gap between minor versions at about four months. Read together with the two-branch model, that produces a predictable rhythm: work accumulates on develop, a candidate is cut about a week before the minor, and master carries the result. Nothing in the visible text explains how long a candidate is expected to stay open or what happens if it regresses, and the repository also carries a RELEASE-NOTES.txt file at the root that is where that story would live.

An Apache 2.0 dependency adds a restriction the BSD grant does not

The licensing section is the most consequential paragraph in a short README. The Stan math library, the core Stan code and CmdStan are licensed under new BSD, while RStan and PyStan are licensed under GPLv3 and the other interfaces carry their own open source licences. Then the caveat: the math library depends on the Intel TBB library, which is licensed under Apache 2.0, and that dependency implies an additional restriction compared with the new BSD licence alone. The text states the consequence directly, that Apache 2.0 is incompatible with GPL-2 licensed code if distributed as a unitary binary, and points at a licensing page on the project wiki for the full argument. In practice this means a licence audit of Stan cannot stop at the BSD grant in the LICENSE file.

The core is BSD and two interfaces are GPLv3, which matters for how you ship it

The split between core and interfaces is worth spelling out, because the interfaces are the part most people touch. CmdStan, the command line interface, sits on the new BSD side along with the core and the math library, so a distribution that ships the C++ binary and the command line tool is working inside the BSD terms plus the TBB restriction. RStan and PyStan are GPLv3, which changes what you may do with a combined work, and the README notes other interfaces have other open source licences without enumerating them. That last sentence is a real gap for anyone building a compliance matrix: seven interfaces are named across the README and the licences of the ones not called out are not stated there. The tree does carry a licenses directory alongside LICENSE.md, which suggests per dependency notices exist, and the wiki page is where the project intends this to be resolved.

Seven interfaces, none of them in this repository

The interfaces paragraph names R, Python, MATLAB, Julia, Stata, Mathematica and the command line, and the interfaces section states that separate repositories exist in the stan-dev GitHub organization for the interfaces and for the higher and lower level libraries. So this repository is the C++ core plus the command line path, and everything a typical user reaches for first lives somewhere else with its own version, its own licence and its own release schedule. The source repository section then says something close to the same thing again, that the source code repository is hosted here on GitHub, which is true but adds no new information. What is missing from the visible text is any statement about how the interfaces pin the core: whether they track a tag of this repository or build against develop is exactly the question a user upgrading a model needs answered.

A makefile, a make directory, a Python test runner and two CI systems

The tree describes the working arrangement without narrating it. There is a makefile at the root and a make directory beside it, so the build is split between a top level entry point and a set of fragments rather than kept in one file. Tests are driven by runTests.py, a Python script in a C++ library, which tells you the test harness expects an interpreter to be present. Formatting is fixed by .clang-format. .gitmodules is present as well, so at least one dependency arrives as a submodule rather than being vendored, which fits the README's statement that the math library is a separate project. Then there are two continuous integration systems: a Jenkinsfile at the root and a .github directory. As with other long lived C++ projects, that combination usually means one is legacy, and nothing visible here says which one gates a merge.

The home page is linked over http, and a Zenodo DOI does the archiving

Two small details close out a README of 239 words. The home page section links the project's site as http rather than https, which is an odd choice for a project whose downloads include source archives, and the same http form appears in the badge link at the top. Against that, the project does cite a DOI for archiving, with a Zenodo badge pointing at a concept identifier that mints a fresh citation for each release. For a numerical library, that is the more important of the two: a Bayesian result is only reproducible if the exact sampler version, the math library version and the data are recoverable, and a per release DOI is what makes the software half of that citable. The tree also carries RELEASE-NOTES.txt, which is where a reader would look to tie a version to a change.

Editorial conclusion

stan-dev/stan is for someone writing the sampler, the autodiff layer or the command line interface, not for someone who wants to run a model. If you want to run Stan, use one of the interface repositories and let them pin a release. Four things to settle before you build anything from this repository. The default branch is develop, which holds the latest stable development, while master holds the current release, so an unqualified clone is ahead of what v2.40.0 contains. Read the licensing section rather than the licence file: RStan and PyStan are GPLv3 while the core is new BSD, and the Apache 2.0 dependency in the math library adds a restriction that makes GPL-2 code incompatible in a unitary binary. The build is a makefile plus a directory of fragments with a Jenkins pipeline, so expect to meet that toolchain. And the interfaces live in seven other repositories, each with its own licence and its own release cycle.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. stan-dev/stan on GitHub