Resonic Testing

This document is intended for people interested in testing the latest Resonic Pro builds.
Resonic Player pre-release builds are freely available to the public.


Anybody may become a tester, but for being involved with the Testing Team these are the basic requirements:

  1. Be on
  2. Report back every now and then
  3. Stick to current testing goals, if any have been set
  4. You have to be fine with watching video streams of new features and occasional voice chats
  5. All Player Alphas and Betas a freely available to the public
  6. All Pro Alphas and Betas are available to testers only
  7. You do not need a Pro license for Alpha testing, but for Beta testing (see below)

Discord Channels

We use Discord to keep things central and semi-public. For private Pro testing these are the main channels:

  • During Alpha phases: #alphatest and 🔈alphatest-voice
  • During Beta phases: #betatest and 🔈betatest-voice
  • All testing channels are locked by default — please request to be added to them.
  • Nicknames of active testers have a yellow tint.
  • In case you need logins to access some downloads check the pinned messages on the Discord channels (Ctrl+P).

If you're testing public Resonic Player pre-releases please use the public channels #resonic, #bugs, and #suggestions.

Other means of reporting:

How to Test

That's really up to you.

Read: How to use Test Builds (Alpha + Beta)

Testing shouldn't be tense, mechanical, or over-complicated.
Everybody has their own way of testing software and we're not going to force ours onto you.

But: As stability and flawless function is the main goal, try whatever you want, in any order, go into detail with each new feature you can relate to, torture it, try to break it. Sit in a Discord channel and report things as they happen, retreat for a few days, take notes, and come back with the results, use the bug tracker if you must, it's up to you.

Sometimes we set goals, things to focus on, things that most need testing at the moment. Typically it's certain features that are going to be in the next release. We'll then have a scheduled voice chat, quite possibly with video stream, on one of the 🔈alpha|betatest-voice channels to present some feature details that are easier expressed like this.

As a tester be in touch, even if it's just for a heads-up about not having found anything new, or not having much time on your hands.

Your extra set of eyes and brain is the help we need. But it's only helpful if you come forward with your findings and updates.


Get the latest .zip (Alpha and Beta) or .msi file (Beta) from the stuff space.
Pro + Player Alpha check:
Public builds:
Private builds: (testers only)

Make it a habit to read the changelogs for every new build. They tell you what has been added or modified. They use the same name as the build .zip, but with .txt extension, and are included with every build and release as whatsnew.txt.

You can find the latest builds here, and a tool to help you spot differences between two whatsnew.txt files here.

If you're new, here's an introduction to Test Builds (Alpha + Beta).

File Naming Scheme

The naming scheme of all Setup and Portable builds sticks to:


For example:

Testing Cycle

A new testing cycle begins in May 2024, the existing testers group on Discord was wiped.

Since Resonic Pro 0.9.5 is undergoing a DRM minimization:

  • Pro Alpha builds can now be tested without a Pro license. Alpha builds expire after a while.
  • Pro Beta builds require a working Pro License which you either already own, or will be provided to you. A QA License allows you to test any build we release in full and without restrictions. You can also run official releases with the same license. To avoid hit and runs these licenses are time-limited and expire after a few months. They are renewed on an activity basis, as long as you don't completely disappear.

Public Channels

On Discord, anything private related to Alpha and Beta testing goes in the channels mentioned at the top of this page.

Anything related to Official Releases, or that might be of general interest, belongs in #bugs, #suggestions, or #resonic.
These channels are public, everyone can see what you post there. Other people might join in to the conversion.

There are also public voice channels for group talks and brainstorming (🔈kitchen and 🔈studio).

That's it really

But if you feel like there's more to be added here, say the word.

Looking forward to seeing you on Discord.


Here's the basic terminology we've been using in the past, and are still using now:

The first phase of new software is usually called Alpha, and we used this label for the first few releases, but won't be using it again, except maybe for new products.
Resonic has been a permanent Beta and never really left this phase, which means that we haven't had a standard beta/release cycle so far, but unstable/Beta. We'll leave the permanent beta phase with the 0.9.4 release.
Special builds that are intended for preview and testing purposes only, never intended for production use. This is really what should be beta in a healthy beta/release cycle. Unstables will become Alphas after the 0.9.4 release.
Early Access
The phase we're in where Resonic is sold for an introductory price, and to support further development, without resorting to other forms of crowd-funding. We intend on leaving this phase sometime after the 0.9.4 release.
Pre Release
Any build not intended for public release, i.e. unstable, alpha, beta (in a normal cycle), release candidate.
The Windows Installer .msi version of Resonic that can be installed properly into your system's Program Files folder.
The .zip version of Resonic that is not installed, but can simply be unpacked into a location with write-access, e.g. your Desktop, and run from there. All files remain in that folder, and it can be deleted after testing without leaving behind any traces. All Alpha versions are portable versions.
The automated process of preparing, building, and packaging a version of a program so that it can be delivered to the testers, or end users.
What a program is called after being built
build number
A number that increases between successful builds, it describes how often the build process had to run to get to this version. Typically identifies one unique version of a program, and is part of the version number.
We use two or three part version numbers (major.minor.revision) and a build number, e.g. 0.9, 0.9.4, The revision part may go past 9, e.g. 0.9.15