Tvheadend

h1. Release Process

There have been a few questions about the Tvheadend release process and numbering scheme, so I thought I would try and clarify a few things.

h2. Version Numbering

Tvheadend uses a standard MAJOR.MINOR.PATCH numbering system, though we omit PATCH for the first release in a given series, i.e. 3.2.

The PATCH number is not incremented on each release, but is automatically calculated using the __git describe__ command. This simply provides a PATCH number that represents the number of commits since the last git tag.

E.g. the first patch release of the [[Tvheadend-32|v3.2]] series is 3.2.18 (as there were 18 commits since 3.2).

The __git describe__ command will also add ~COMMIT for all builds except the first in a release series. The COMMIT field is the git SHA1 code that represents the commit from which the build was made.

Note: when reporting bugs the most useful thing to include is the full MAJOR.MINOR(.PATCH~COMMIT) information as reported in the TVH UI.

h2. Development Cycles

As of [[Tvheadend-30|v3.0]] Tvheadend uses an odd/even MINOR number to distinguish development cycles from releases. Therefore [[Tvheadend-30|v3.0]], [[Tvheadend-32|v3.2]] and [[Tvheadend-34|v3.4]] represent stable releases and v3.1, v3.3, etc.. are used to represent development cycles.

All builds from the git master branch will use development numbers.

h2. Release Branches

Once a release series is ready to enter feature freeze (beta stage) a release branch will be created, vX.Y will have the branch release/X.Y.

All release related work will be done here, fixes will normally first be committed to master and they __cherry-picked__ into the release based on whether they are considered critical enough etc...

h2. Beta's and pre-releases

Because of the use of automated versioning using __git describe__ pre-release versions will always have a development version number from the preceding development cycle. I.e. 3.2beta5 was officially known as 3.1.773~gc74b0cf.

h2. Tagging

The first release of a series is always tagged vX.Y, this format is distinguished by our versioning scripts that wrap the __git describe__ command, so that we get consistent automatic numbering from this point.

When a release X.Y is branched a new commit will be added to master and tagged vX.Y+1 to indicate a new development cycle has begun on master ready for the X.Y+2 release.

Finally pre-release and patch releases are always tagged X.Y(beta|rc|patch)N to make it clear from where they were built. The v prefix is omitted so that these do not interfere with the automatic versioning system.