-
Notifications
You must be signed in to change notification settings - Fork 19
/
Copy pathversion-numbering.Rmd
112 lines (90 loc) · 3.55 KB
/
version-numbering.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
# Version Numbering {#versionnum}
All _Bioconductor_ packages should have a version number in x.y.z format.
Examples of good version numbers:
1.2.3
0.99.5
2.3.0
3.12.44
## Even Odd Schedule
_Bioconductor_ has a 'devel' branch where new features are introduced,
and release branches created twice per year. Given a package with
version number x.y.z,
* y should be an odd number in devel.
* y should be an even number in release.
During regular development of new features
* Authors increment the z version of their package in the 'devel'
branch by 1 for each GIT commit, e.g., from 1.1.0 to 1.1.1, 1.1.2,
..., 1.1.10, 1.1.11
* Any bug fixes ported to the release branch are similarly
incremented, 1.0.1, 1.0.2, ...
* Changes made to GIT without a corresponding version bump **do not
propagate** to the repository visible to `BiocManager::install()`.
At the time of a release, the _Bioconductor_ team arranges to:
* Create a release branch package with version: x **.** (y+1) **.** (z-z)
* Increment the devel branch package version to: x **.** (y+2) **.** (z-z)
* As a special case, any package with version x.99.z is bumped to
(x+1) **.** 0 **.** (z-z) in release, and (x+1) **.** 1 **.** 0 in devel.
Thus authors wishing to signify a major change to their package should set y
to 99 in their devel package.
## New packages
New packages submitted to _Bioconductor_ should set Version: 0.99.0 in the
DESCRIPTION file. Specifying y=99 triggers a bump in x at the next release
which in this case results in version 1.0.0.
See additional details on the [Package Submission](#subintro) page.
See also the instructions for [Using Bioc Devel]['devel' version].
## Example Cases
1. Normal Case. Suppose a package in the devel branch has version
number 1.1.25. The new release branch now contains a copy of the
package with version 1.2.0. The devel branch of _Bioconductor_
contains the package whose version number has been bumped to
1.3.0
2. Special Case. The "0.99.2" version of our package is copied by the
_Bioconductor_ team to the release branch with version number
1.0.0. The package version is bumped to 1.1.0 in the devel
branch.
Examples of the version bumping scheme:
<table border="1" cellpadding="5" cellspacing="0">
<thead valign="bottom">
<tr>
<th class="head">Current Release</th>
<th class="head">Current Devel</th>
<th class="head">Just before Next release</th>
<th class="head">Next release</th>
<th class="head">Next devel</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td>--</td><td>0.99.1</td><td>0.99.2</td><td>1.0.0</td><td>1.1.0</td>
</tr>
<tr>
<td>1.4.0</td><td>1.5.0</td><td>1.5.4</td><td>1.6.0</td><td>1.7.0</td>
</tr>
<tr>
<td>1.4.0</td><td>1.5.0</td><td>1.5.1</td><td>1.6.0</td><td>1.7.0</td>
</tr>
<tr>
<td>1.4.0</td><td>1.5.0</td><td>1.99.3</td><td>2.0.0</td><td>2.1.0</td>
</tr>
<tr>
<td>1.8.0</td><td>1.9.0</td><td>1.9.1</td><td>1.10.0</td><td>1.11.0</td>
</tr>
</tbody>
</table>
<br />
## Summary
Below is a summary of how version components are bumped and the
key limitations. Bumps "at release time" are done by the _Bioconductor_
team and not the package maintainer.
`x`
- only modified by the _Bioconductor_ team
- bumped to x+1 at release time if y=99
`y`
- must be even in release and odd in devel
- must be <=99
- bumped at release time for all packages to the next
even number in release and the next odd in devel
`z`
- should be incremented sequentially during regular package development
- no limitation on the size of z
- bumped at release time to 0 for all packages.