Skip to content

Module Versioning

Context and Problem Statement

We want to have a modular product with well defined interfaces between components. Due to modularization, more and more software modules are required to compose the product. Choosing always the latest version of these dependent software modules, may break the product or stall progress as changes must be coordinated. Therefore, these dependencies must be documented and managed to be able to evolve the product.

How do we therefore want to Version the components and their interfaces in order to communicate changes to other users of the component/interface?

Decision Drivers

  • How can we identify and document the software that is installed on a system?
  • How can we identify if changes to software modules are compatible with the existing software?
  • How can we identify what changes are more recent?
  • How can we automatically choose newer software modules that are compatible with the existing software?
  • How can individual software modules progress without negatively influencing other software modules?

Considered Options

Decision Outcome

Chosen option: "Semantic Versioning" because,

  • It is easy to learn and understand - yet very effective.
  • Knowing the release date of a software module is less important than knowing its (promised) compatibility and the risk associated with the change.

Pros and Cons of the Options

Semantic Versioning

Positive:

  • widely adopted version scheme that is oriented towards the end user (i.e., the consumer = developer)
  • well-suited for automation (e.g. testing + updating dependencies to the latest non-breaking version)
  • risk and changed functionality part of the version
  • compatibility reflected in the version
  • by default, Nuget assumes semver compatibility
  • broad support for the .. version core

Negative:

  • release date not encoded in version
  • potential of failing to signal breaking changes (i.e., failing the Promise Theory)