Release Process

There have been a few questions about the Tvheadend release process and numbering scheme, so here are notes for the release process.

Version Numbering for 4.x

Tvheadend uses a standard MAJOR.MINOR.PATCHLEVEL numbering system for the stable releases and MAJOR.MINOR[.PATCHLEVEL]-CHANGES for the development releases. The first stable release is v4.0.1.

The PATCHLEVEL number is incremented on each release and appropriate vMAJOR.MINOR.PATCHLEVEL tag is created in the git repository to allow obtain tar ball packages through github - https://github.com/tvheadend/tvheadend/releases .

The git describe command will also add CHANGES~COMMIT for all builds except the first in a release series. The CHANGES field determines number of changes after previous tag. 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[.PATCHLEVEL][-CHANGES~COMMIT] 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, v4.1, v4.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.L (where L is initially 1), 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.

For development (odd Y numbers), there are no more tags than the first one like v4.1. The number of changes (commits) in the branch is distinguished by number after minus sign like v4.1-75-g2c8f91a .

Version Numbering for 3.x

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.