Version Numbering

Version Format

All Bioconductor packages should have a version number in x.y.z format.

Examples of good version numbers:


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,

During regular development of new features

At the time of a release, the Bioconductor team arranges to:

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.


  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:

Current Release Current Devel Just before Next release Next release Next devel


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.