Project Policies: PR's, compiler warnings, release cadence, etc.

We appreciate community interest in Basis Universal. To ensure the project's stability and our ability to manage development (and our testing bandwidth) effectively, please review these guidelines before submitting PRs.

Release Cadence and PR Merging

We aim to release at least one major update to Basis Universal each year. Development for these releases typically occurs in a private fork of the repository, after which the changes are merged back into the public repository.

To amortize testing costs and minimize merge overhead, we prefer to merge substantial or impactful PRs as part of these major releases, rather than incrementally. This approach helps ensure stability while allowing us to validate changes as part of a larger, well-tested release cycle.

If we find a serious bug or security issue, we will rapidly check the changes into the main repo and document the change in the Release Notes.

PR Submissions

We are conservative when accepting code PRs. If we tried to accept every PR submitted from the internet, we would spend most if not all of our available time merging, testing and fixing these PR's, instead of developing new codecs or features. Many PR's we've seen introduce painful or subtle regressions.

Documentation-only PRs are held to a lower bar. Build (CMake) related changes have a very high bar. Core codec related changes have the highest bar. Scoped C-API and Python related additions, changes, or examples have a lower bar because that part of the system is still very new and we are not Python experts.

Non-trivial PRs trigger a building and testing cycle on our end, and this takes up our time and bandwidth. We may not be able to accept a PR because it conflicts with the next major release that you cannot see yet in a private repo, and we can't tell you exactly why yet because we're under an NDA. Even seemingly simple changes can introduce subtle regressions, particularly in core systems or codecs, that may not be apparent without deep familiarity with the codebase, GPU texture formats, signal processing, or data compression.

Please keep PRs as narrowly scoped as possible. Changes to core systems or codecs require especially strong justification. At a minimum, PRs should be thoroughly tested on:

• Linux (GCC and Clang)
• macOS
• Windows (latest MSVC x64)
• Emscripten (WebGL builds)
• WASM WASI builds

In cases where a proposal is compelling but the implementation raises concerns, we may choose to implement the change or fix internally rather than merging the PR as submitted, then batch the change into the next major release.

Compiler Warnings

We primarily care about warnings produced by the compilers and compiler versions we actively test with, as well as newer versions. The exact compiler versions used for testing are documented in our README. Our primary compiler (i.e. the compiler actively develop with) is the latest version of MSVC x64, because it has by far the best native debugger, followed by clang and gcc.

Warnings from older compiler versions may be spurious or already addressed in newer compiler versions. Spending excessive time investigating these warnings would significantly slow progress on adding new features and codecs.