All Bioconductor packages should have a version number like x.y.z. Here are examples of good version numbers:
1.2.3 0.0.1 0.4.5 2.3.0
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.
Given a package with version number x.y.z,
The Bioconductor team will bump y as part of the release process.
Here is a table showing examples of the version bumping scheme:
|Release||Devel||Just before release||Next release||Next devel|
|1.4.0||1.5.0||1.5.0||1.4.0 (no changes)||1.5.0|
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.
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.