Decremental Versioning 42.0.69

decrement a gradual decrease in quality or quantity

“Decrement.” Merriam-Webster.com Dictionary, Merriam-Webster, https://www.merriam-webster.com/dictionary/decrement. Accessed 25 Feb. 2023.

Summary

All software projects start at a version number that communicates the expected lifespan of the project. Given a version number MAJOR.MINOR.PATCH, decrement the:

  1. MAJOR version when the MINOR version reaches zero
  2. MINOR version when the PATCH version reaches zero
  3. PATCH version when new releases are available

To help simplify development and distribution, pre-release and build metadata are optional.

Introduction

Modern software development is complicated and often relies heavily on the work of open-source projects or other contributions from outside an organization. This practice often accelerates development and promotes reusability but can expose an organization to dependency supply chain attacks.

A dependency supply chain attack is a cyberattack that targets the software supply chain by injecting malicious code into a software package's dependencies. This attack works by compromising one of the components or libraries a software package relies on, which can then spread to other software packages using the same component or library.

Here's an example of how a dependency supply chain attack might work:

  1. An attacker identifies a widely-used software component or library with a vulnerability or weakness.
  2. The attacker then injects malicious code into this component or library, which can propagate to other software packages.
  3. The compromised component or library is distributed to other software developers through a package manager or repository.
  4. Other software developers unknowingly use the compromised component or library in their software packages.
  5. Once the compromised component or library has been distributed in enough software packages, the attacker can launch an attack by exploiting the malicious code they injected.

Dependency supply chain attacks can be challenging to detect and mitigate because they often occur at a level that is outside individual software developers' control. This document proposes a versioning scheme to help mitigate the likelihood and impact of dependency supply chain attacks.

Decremental Versioning Specification (DecVer)

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

  1. When looking to deploy the first release of software distributed using DecVer, the developer MUST anticipate the total number of MAJOR versions of the software and the number of MINOR and PATCH versions within the first release. This practice helps to communicate the expected product lifespan to consumers and potential investors.
  2. A version number MUST take the form of X.Y.Z, where X, Y, and Z must be integers.
  3. Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version. The only exception to this rule is if the new version introduces a breaking change and is published before a long holiday weekend (disabling notifications is recommended in this scenario).
  4. The PATCH (x.y.10) MUST always be decremented by one for each release, regardless of the MAJOR or MINOR releases. PATCH version numbers MAY be negative.
  5. The MINOR (x.32.z) MAY be decremented by one for each release. An arbitrary number MAY be selected, depending on pressure within an organization to reach a particular version milestone or based on the maintainer's opinion on the release day.
  6. The MINOR (x.32.z) MUST always be a positive integer. If a release would cause the MINOR version to be negative and the maintainer is not ready (or willing) to issue a new MAJOR version number, an arbitrary number MUST be selected that is higher than the initial MINOR version number.
  7. The MAJOR (42.y.z) version number must be decremented when the MINOR version reaches zero or when software maintainers need to communicate the approaching end of a product's lifespan.
  8. If two or more subsequent releases have been bug-free, a new version of the package MUST be released that introduces breaking changes. Under these circumstances, the MAJOR and MINOR version numbers MUST NOT be changed.
  9. If a bug or issue is discovered in a previous release, the fix MUST be implemented in a subsequent release with a lower MAJOR version number. For example, if a bug is discovered in version 95.2.3, the fix will be implemented in version 94.3.1.
  10. Release notes MUST be composed only of the version number.
  11. If the MAJOR version number reaches zero, the package or software MUST immediately be removed from all package managers or repositories.

Why use Decremental Versioning?

Practicing Decremental Versioning encourages software or package consumers to engage in careful dependency review out of necessity. Reviewing software dependencies and pinning dependencies to a specific version are essential practices in software development that provide several benefits:

About

Out of caution, this page is satire. Please use a sensical versioning scheme, such as Semantic Versioning, and periodically review and audit your project's dependencies.

Created by John Koster.

License

Creative Commons ― CC BY 3.0.
This work adapts language from the Semantic Versioning specification.