22 Version Numbering
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.4422.1 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.
22.2 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 page.
See also the instructions for Using Bioc Devel.
22.3 Example Cases
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
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:
| Current Release | Current Devel | Just before Next release | Next release | Next devel |
|---|---|---|---|---|
| – | 0.99.1 | 0.99.2 | 1.0.0 | 1.1.0 |
| 1.4.0 | 1.5.0 | 1.5.4 | 1.6.0 | 1.7.0 |
| 1.4.0 | 1.5.0 | 1.5.1 | 1.6.0 | 1.7.0 |
| 1.4.0 | 1.5.0 | 1.99.3 | 2.0.0 | 2.1.0 |
| 1.8.0 | 1.9.0 | 1.9.1 | 1.10.0 | 1.11.0 |
22.4 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.