Version Numbering

All Bioconductor packages should have a version number like x.y.z. Here are examples of good version numbers:


The Meaning of x

Packages in the devel repository with version numbers matching 0.y.z are assumed to be too young for release and will not be included in any releases. The exception to this rule is the special version number 0.99.z which we reserve for packages which will become 1.0.0 when bumped into the release.

Even Odd Schedule

Given a package with version number x.y.z,

The Bioconductor team will bump y as part of the release process.

Example Changes

Here is a table showing examples of the version bumping scheme:

Release Devel Just before release Next release Next devel
-- (no changes)1.5.0

The Importance of Incrementing Version Numbers

Developers should get into the habit of bumping the z portion of their version number every time they commit changes to their package.

If you don't bump the version, the changes you made to your package will not propagate to the Bioconductor web site and package repository. This means, for example, that if you fix a bug and commit a bug fix, but don't bump the version, users who download your package will still experience that bug.

There is one circumstance in which you may want to avoid bumping the version number when committing a change. That is when you want to see if a given change will build on all platforms on our nightly build system, and whether dependencies will be affected by the change. When you are satisfied that your change is acceptable, you should bump the version.

Historical Note

The even/odd scheme was introduced as part of the BioC 1.7 release. For this release, all packages going into the release had their y digit incremented to the next largest even number. Then in devel, all packages had y incremented again so that all packages begin the 1.8 release cycle with an odd y digit and z equal to zero.

Fred Hutchinson Cancer Research Center