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.1 is displayed as 1.7.1 in the UI for higher readability (1st patch of 1.7 release).

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.

Contributing

If you want to contribute with a bugfix or a feature:

  • Fork the FlaxEngine, create a new branch, and push your changes there. In most cases, use master branch as a base for changes unless it breaks APIs or provides very new functionality that might need more ongoing work to implement, stabilize, and test before shipping to users. In that case, use the future engine version branch (eg. if the last update was Flax 1.12, then branch off from 1.13 which is used for the next update).
  • Create a pull request. Make sure to describe as to what led to the fix for better understanding; for small and obvious fixes, this is not really needed. However, make sure to mention the relevant issue where it was first reported, if possible.
  • Generally, good code quality is expected, make sure your contribution works as intended and is appropriately commented where necessary.
  • After we positively review and test it, PR will be merged. Your change will appear in the Release Notes and your nick in the contributors list.

Thank you for taking interest in contributing to Flax!

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).