Skip to contents

Version numbering

Source: vignettes/articles/VersionNumbers.Rmd
VersionNumbers.Rmd

Not a programmer? You still need to be aware of what version of Hector you’re using, and how it relates to previous versions.

Generally, Hector follows Semantic Versioning. Briefly, this means that given a version number MAJOR.MINOR.PATCH, we increment the:

  • MAJOR version when we make incompatible API, input, or output format changes,
  • MINOR version when we add functionality in a backwards-compatible manner, and
  • PATCH version when we make backwards-compatible bug fixes.

Note however that because Hector is a scientific model our definition of “backward compatible” does not mean that the results won’t change, only that your previous input files, APIs, and output scripts will still work. In other words, if the version number changes, outputs may change!

Example Version Change
Internal change, not externally visible No change
Bug fix, changes model results PATCH
New variable in output stream MINOR
New parameter, backward compatible1 MINOR
New component, backward compatible2 MINOR
New parameter, not backward compatible3 MAJOR
New component, not backward compatible4 MAJOR
Name or unit change for parameter or output5 MAJOR
  1. E.g. x was internal, can now be set via input, but if not present the old default value is used.
  2. E.g. a new seaIce component that doesn’t require any inputs (assumes if not present).
  3. E.g. a new x that is required to run.
  4. E.g. a new seaIce component that requires inputs.
  5. See issue #79 about associating units with input parameters.