This page describes the current development and release strategy. See Releases for a roadmap of current and past releases.

History / Motivation[]

Original release strategy discussion in the forum

Prior to the adoption of this strategy, there was a single "autobuild" which was both the development trunk and the only version readily available to end users. This made it extremely difficult to implement major changes without negatively impacting users.

Process overview[]

  • A stable release is maintained for bug fixes and ports.
  • New features and other major changes to the core code are implemented in an unstable development branch.
  • At intervals, the development branch will enter a period of stabilization.
  • When the result is judged sufficiently stable, a new stable branch is made, and development of the next version proceeds in the development branch.

Version numbering[]

Starting with the 1.4 release, the 3rd digit of the version number is incremented on release, so builds from the 1.4 development branch are 1.4.0.x, while builds from the stable release branch are 1.4.1.x. See [1] for discussion.

Development branch[]

The development "branch" is always the trunk, found at

All major new features or code re-writes will be done in the development branch.

Autobuilds of the development branch are available from

Development branch lifecycle[]

  1. Release branch N created, released as 1.N.1, development for N+1 proceeds in trunk as 1.(N+1).0
  2. Active development phase
    • Release branch recommended for users and new ports
    • Development of major / disruptive features
  3. Stabilization phase
    • Major features complete
    • Development builds suggested for users who want new features
    • Low risk features may be added
  4. Release candidate phase
    • Development branch recommended for users
    • New ports go in development branch, not back ported by default
    • Focus on bug fixes
  5. Release - GOTO 1

Stable branch[]

The stable branch represents a "release" where major functionality and features are frozen. New ports may be added to the stable branch.

The stable branch will always be named release-N_M, where N and M are the major and minor version numbers. See the Releases page for the current stable branch.

Autobuilds from the stable version are available from

Important: stable refers to the feature set, not necessarily the maturity of the software. Stable does not mean that all features are fully functional on all cameras, or that the software won't crash.

Individual ports within the stable branch may vary widely in completeness and functionality. Individual ports will be labeled Alpha or Beta as appropriate.


It is currently recommended that new ports be developed for the release branch, and ported to the trunk when complete.