Overview

Releases will be numbered with the following semantic versioning format:

#!r

<major>.<minor>-<patch>

E.g.: 2.0-1

And constructed with the following guidelines:

• Breaking backward compatibility bumps the major (and resets the minor and patch)
• New additions without breaking backward compatibility bumps the minor (and resets the patch)
• Bug fixes and misc changes bumps the patch

For more information on SemVer, please visit http://semver.org/.

Explanation

The main reason for package versioning is to indicate the (slight or significant) differences among different versions of the package. To be most useful versioning requires the enforcement of the following versioning rules (many borrowed from semantic versioning):

• a version number is of the form major.minor.patch (x.y.z), e.g., 0.1.7
• only the version x.y is released to CRAN
• x.y.z is always the development version, and each time a new feature or a bug fix or a change is introduced, bump the patch version, e.g., from 0.1.3 to 0.1.4
• when one feels it is time to release to CRAN, bump the minor version, e.g., from 0.1 to 0.2
• when a change is crazy enough that many users are presumably going to yell at you (see the illustration above), it is time to bump the major version, e.g., from 0.18 to 1.0

Thus the version 1.0 does not imply maturity; it is just because it is potentially very different from 0.x (such as API changes); same thing applies to 2.0 vs 1.0

Rule #3 is borrowed from Michael Lawrence (author of RGtk2) and I think it is a good idea. In particular, it is important for brave users who dare install the development versions. When you ask them for their sessionInfo(), you will be aware of which stage they are at.

Rule #2 saves us a little bit of energy in the sense that we do not need to write or talk about the bio3d package 1.3.548, which is boring but just say bio3d 1.3.