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.

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 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 information as reported in the TVH UI.

Development Cycles¶

As of v3.0 Tvheadend uses an odd/even MINOR number to distinguish development cycles from releases. Therefore v3.0, v3.2 and 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.

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

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.

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.