Flax Release Policy
This document covers the Flax Engine release plan and describes the versioning method.
Versioning
Flax uses versioning based on the major.minor[.build[.revision]] formula, where:
- Major: major version number, changed when a new product version arrives with a significant number of changes including heavy API refactoring and design concepts modifications.
- Minor: minor version number, changed after engine updates which bring quality improvements and new features. Upgrades between minor engine versions are rather easy as only single APIs can differ.
- Build: build number that is incremented every engine release and is used also for maintenance bugfix updates. It doesn't affect the API.
- Revision: revision of the version. Used to differentiate revisions of the same engine release (as patches). For example,
1.7.6403.1is displayed as1.7.1in the UI for higher readability (1st patch of1.7release).
The same versioning schema is used for binaries (both native and managed C#) and game or project files.
Branching
The combination of major.minor is called stable branch and is used in separation for maintenance and support (see branches). This way we can apply hotfixes and security updates separately for multiple releases (the latest one and the past ones if needed).
Most of the active development work happens on the master branch, which is used for the next engine update. Changes can also be backported from master into specific release branches. Shortly after stable releases we keep `master`` for hotfixes and further stabilization (e.g. 1-2 weeks) and wait before merging any new features or breaking changes.
Support
Stable updates (eg. 1.7, 1.8) are targeted to be released approximately every 4 months. Then, we support the latest released stable version with patch updates (eg. 1.7.2, 1.7.3).
Any deprecated features or APIs are maintained for at least a year before removal. Changes to the content data or project format are maintained for at least two years (due to backward compatibility reasons).