ReleaseProcess » History » Version 1
Adam Sutton, 2012-11-07 13:29
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.
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.