Andy Beet

Andy Beet

Research Scientist and Analyst

Semantic versioning

2 minute read

Published:

The official site for Semantic versioning is available in many languages indicating, in part, how important this subject is across the world for software development. It provides a clear, standardized way to communicate the nature of changes between releases, which helps manage dependencies and predict the impact of updates. By using a version format like MAJOR.MINOR.PATCH, developers indicate whether an update is a backwards-incompatible breaking change (MAJOR), a new backwards-compatible feature (MINOR), or a backwards-compatible bug fix (PATCH).

In the development of R packages it is no different. Let’s dive a little deeper with some examples. Following semantic versioning we adopt the format of MAJOR.MINOR.PATCH. For example v3.5.1. The interpretation of these three components can be a little confusing, especially in the context of R package development.

  • Changes in the PATCH component refer to small changes, like bug fixes. It is assumed that these changes do NOT break any existing code. They are “backward compatible”. Nothing changes in the package except an error has been corrected
  • Changes in the MINOR component refer to changes such as new features. These new features integrate with the package, they complement other features already present, and do NOT break existing code.
  • Changes in the MAJOR component refer to changes that would break existing code. For example, if a user was using a particular function in your package, and you changed the code in this function that resulted in a different output structure, the users code would break. This would be “backward incompatible”

Examples

Suppose a package is currently at version 3.5.1

  • If one or more bugs were fixed (PATCH), the next release would be version 3.5.2
  • If a new feature was added (MINOR), the next release would be version 3.6.0. (Note, the PATCH is reset to zero. It would not be 3.6.1)
  • If a new breaking change was added (MAJOR), the next release would be version 4.0.0. (Note, both MINOR and PATCH are reset to zero)
  • If several bugs were fixed (PATCH) and a couple of new features (MINOR), the next release would be version 3.6.0. (Note, default to the higher order change, MINOR)
  • If several bugs were fixed (PATCH), a couple of new features added (MINOR), and a restructure of the package (MAJOR), the next release would be version 4.0.0. (Note, default to the higher order change, MAJOR)

I think you get it! Enough said.

You May Also Enjoy

Go get an ORCID iD!

1 minute read

Published:

What is an ORCID iD? Should you get one? What can you do with it? If you are a researcher or a scholar it might be worth you signing up for one. Here’s why …

Enhancing an R package

6 minute read

Published:

So you want to create an R package? Well there are a ton of resources available to help with this, the best being the official book from the Posit folks, R Packages (2e). However, after the initial set up, organization, and implementation of the package there are several other related components you should think about including to make it function, look, and feel polished!

Versioning R packages

3 minute read

Published:

You’ve reached the point in which you want to officially start to version your R package. How do you go about doing this? When should you version? How often? What versioning scheme should you use? How do you document the changes?

Automate versioning for R data packages

2 minute read

Published:

Do you find yourself downloading data from a server over and over again to make sure you have the latest data? Then struggle to work out what’s changed from the last time you downloaded it?