ReleaseProcess » History » Revision 2
Revision 1 (Adam Sutton, 2012-11-07 13:29) → Revision 2/3 (Jaroslav Kysela, 2015-05-26 12:24)
h1. Release Process
There have been a few questions about the Tvheadend release process and numbering scheme, so here are notes for the release process. I thought I would try and clarify a few things.
h2. Version Numbering for 4.x
Tvheadend uses a standard MAJOR.MINOR.PATCHLEVEL MAJOR.MINOR.PATCH numbering system system, though we omit PATCH for the stable releases and MAJOR.MINOR[.PATCHLEVEL]-CHANGES for the development releases. The first stable release is v4.0.1. in a given series, i.e. 3.2.
The PATCHLEVEL PATCH number is not incremented on each release and appropriate vMAJOR.MINOR.PATCHLEVEL tag release, but is created in automatically calculated using the __git describe__ command. This simply provides a PATCH number that represents the number of commits since the last git repository to allow obtain tar ball packages through github - https://github.com/tvheadend/tvheadend/releases . 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[.PATCHLEVEL][-CHANGES~COMMIT] 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, v4.1, v4.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.L (where L is initially 1), 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.
For development (odd Y numbers), there Finally pre-release and patch releases 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 .
h2. 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 [[Tvheadend-32|v3.2]] series is 3.2.18 (as there always tagged X.Y(beta|rc|patch)N to make it clear from where they were 18 commits since 3.2).
built. The __git describe__ command will also add ~COMMIT for all builds except the first in a release series. The COMMIT field v prefix is the git SHA1 code omitted so that represents these do not interfere with 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.
automatic versioning system.
There have been a few questions about the Tvheadend release process and numbering scheme, so here are notes for the release process. I thought I would try and clarify a few things.
h2. Version Numbering for 4.x
Tvheadend uses a standard MAJOR.MINOR.PATCHLEVEL MAJOR.MINOR.PATCH numbering system system, though we omit PATCH for the stable releases and MAJOR.MINOR[.PATCHLEVEL]-CHANGES for the development releases. The first stable release is v4.0.1. in a given series, i.e. 3.2.
The PATCHLEVEL PATCH number is not incremented on each release and appropriate vMAJOR.MINOR.PATCHLEVEL tag release, but is created in automatically calculated using the __git describe__ command. This simply provides a PATCH number that represents the number of commits since the last git repository to allow obtain tar ball packages through github - https://github.com/tvheadend/tvheadend/releases . 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[.PATCHLEVEL][-CHANGES~COMMIT] 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, v4.1, v4.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.L (where L is initially 1), 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.
For development (odd Y numbers), there Finally pre-release and patch releases 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 .
h2. 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 [[Tvheadend-32|v3.2]] series is 3.2.18 (as there always tagged X.Y(beta|rc|patch)N to make it clear from where they were 18 commits since 3.2).
built. The __git describe__ command will also add ~COMMIT for all builds except the first in a release series. The COMMIT field v prefix is the git SHA1 code omitted so that represents these do not interfere with 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.
automatic versioning system.