Project

General

Profile

ReleaseProcess » History » Version 3

Jaroslav Kysela, 2015-05-26 12:31

1 1 Adam Sutton
h1. Release Process
2
3 2 Jaroslav Kysela
There have been a few questions about the Tvheadend release process and numbering scheme, so here are notes for the release process.
4 1 Adam Sutton
5 2 Jaroslav Kysela
h2. Version Numbering for 4.x
6 1 Adam Sutton
7 2 Jaroslav Kysela
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.
8 1 Adam Sutton
9 2 Jaroslav Kysela
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 .
10 1 Adam Sutton
11 3 Jaroslav Kysela
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.
12 1 Adam Sutton
13 2 Jaroslav Kysela
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.
14 1 Adam Sutton
15
h2. Development Cycles
16
17 2 Jaroslav Kysela
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.
18 1 Adam Sutton
19
All builds from the git master branch will use development numbers.
20
21
h2. Release Branches
22
23
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.
24
25
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...
26
27
h2. Beta's and pre-releases
28
29
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.
30
31
h2. Tagging
32
33 2 Jaroslav Kysela
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.
34 1 Adam Sutton
35
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.
36
37 2 Jaroslav Kysela
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 .
38
39
h2. Version Numbering for 3.x
40
41
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.
42
43
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.
44
45
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).
46
47
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.
48
49
Note: when reporting bugs the most useful thing to include is the full MAJOR.MINOR(.PATCH~COMMIT) information as reported in the TVH UI.