Which version should I use?
FileBrowser Quantum comes with two release channels (stable and beta) across v1.5.x, v2.0.x, and v2.1.x. Choosing the right version is an important first step.
Current state: v2.0.x and v1.5.x both ship on the stable channel (v2.0.0-stable is the latest v2 stable release). v2.1.x is on the beta channel. Upgrading from v1.x to v2.0.x requires a one-time migration — see v2 migration guide before changing tags.
Recommended for new users: Start with v2.0.x (stable) for current v2 features, or stay on v1.5.x (stable) if you are not ready to migrate. Use v2.1.x (beta) when you want the newest v2 features before they reach stable.
Release Types
Stable Release (v1.5.x and v2.0.x)
The stable release build is the most reliable version as the name implies. It currently includes v2.0.x (latest: v2.0.0-stable) and v1.5.x maintenance releases. It gets updated less frequently than beta, and is ideal for:
- Those getting started with FileBrowser Quantum
- Users with a userbase that doesn’t want to see occasional bugs
- Production environments requiring stability
- Anyone who prefers proven, tested features
Beta Release (v2.1.x)
The beta release build currently tracks v2.1.x (building on the v2.0.x stable base) and is ideal for those who:
- Don’t have a large userbase
- Want the latest features immediately
- Are comfortable with potential issues
- Want to contribute to development
Beta builds are frequently updated and may encounter unexpected issues. If you run the beta build, it’s encouraged that you participate in beta discussions and open GitHub issues for any new issues found.
Slim Release (for docker only)
stable and beta images have a slim variant. Slim images are much smaller than its counterparts. This is because slim version do not include FFmpeg and document preview bundled along with the image. You can still integrate with OnlyOffice for document editing/viewing. the slim version also supports armv7 platform for devices such as raspberry pi. This is ideal for those who:
- Don’t want preview for files
- Want to save space in disk
Release Cadence
One major difference is the release cadence between the two versions:
Stable
~ 1 to 3 months
Beta
~ 1 to 3 weeks
Major version: v1.5.x vs v2.0.x vs v2.1.x
v1.5.x (stable) | v2.0.x (stable) | v2.1.x (beta) | |
|---|---|---|---|
| Release channel | stable, 1.5-stable | stable, 2.0-stable | beta, 2.1-beta |
| Database | Legacy (database.db) | SQLite (filebrowser.sqlite) | Same as v2.0.x |
| Getting started docs | Migrate via v2 migration guide | v2.0.x guides | Same v2 guides; see beta changelog for v2.1.x-only features |
| Upgrade path | Stay on 1.5-stable for legacy | Default for new v2 installs | Move from v2.0.x when you want v2.1.x features |
| From v1.x | N/A | Follow v2 migration guide | Migrate to v2.0.x first, then beta if desired |
Feature Differences
Eventually, stable release gets all the same features as beta releases, but they lag behind the release schedule. Because of this, features may not come to stable for a month or two.
Other than that, the releases are identical in functionality between major versions.
Version Number Meaning
Versioning follows semantic versioning in format and I try to follow the process version increment. This means:
Major version update (v1.0.0 → v2.0.0)
An overhaul of major features or compatibility differences.
Minor version update (v1.0.0 → v1.1.0)
Can include a collection of features and changes that shouldn't cause any major compatibility issues. All changes should be made in a backwards compatible way.
Patch version update (v1.0.0 → v1.0.1)
For bugfixes, and other minor changes that don't impact functionality.
Stable and beta versions of the same major or minor version should have the exact same features and functionality. However, small differences may exist in patch version updates.
Docker Version Tags
When using Docker, you have access to multiple tag formats for precise version control:
Tag Formats
- Release type tags:
stable,beta,latest- Always point to the latest version of that release type - Full version tags:
1.2.5-stable,1.1.3-beta,2.0.0-preview- Pin to a specific version - Major.minor tags:
1.2-stable,1.1-beta,2.0-preview- Automatically receive patch updates within that minor version - Major tags:
1-stable,2-beta,1-preview- Automatically receive all updates within that major version
Choosing the Right Tag
- For production: Use major.minor tags (e.g.,
1.2-stable) to get bug fixes and security patches while avoiding major version changes - For testing: Use release type tags (e.g.,
beta) to always get the latest version - For stability: Use full version tags (e.g.,
1.2.5-stable) when you need to lock to a specific version
All version tags are available for both regular and slim images. For example: 1.2-stable-slim, 1-stable-slim, etc.
When to Move to Beta Instead of Stable?
I definitely need and welcome anyone that wants to use beta – it’s the best version! But it’s also most likely to see issues.
So, I would recommend using stable unless there’s a feature you need that only exists in beta.
If you move to beta, please join the discussions on GitHub and raise issues for things you see. Having an active beta community is one thing that helps make stable … stable.
What If Stable Has Bugs?
There are two types of bugs in stable:
- Known Bugs:
- Bugs that have existed and are known. Perhaps they require big changes to make work or there’s some other non-trivial reason it’s in stable. Please search GitHub for the issue and see if it is known or if there’s a fix coming that may exist in beta. These type of issues need to be fixed over a longer period of time in beta to ensure there’s no additional unintentional changes as a result of the bugfix.
- New Bugs:
- Bugs that are new and trivial. These bugs probably also exist in beta and have not been discovered yet. If this does happen and the fix is clear and simple, I may update stable directly with a patch release.
All software has bugs – and my stable release may have some still. Stable doesn’t mean it’s bug-free, it means it has a slower and more refined release process to ensure changes happen smoothly.