Life Cycle Versioning - 0.0.1-alpha

An Alternative to Semantic Versioning.

The origin of this concept, can be found here: Life Cycle Versioning on Medium.

Definition

Important

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.

This is the initial version of the Life Cycle Versioning definition. This versioning takes the form of: DECOM.MAINTAIN.RELEASE

Remove Feature — DECOM

Definition

The removal of an existing feature or functionality.

Rules

• The change SHOULD remove a feature.
• The change MAY remove a feature partially or completely.
• The change MAY remove a feature inherently.
• The change MAY remove a feature with or without a replacement.
• The change MAY remove a default or an opt-in feature.
• The change MAY make a previously default feature into an opt-in one.
• The change SHOULD require the attention of the user.

Modify Feature — MAINTAIN

Definition

The modification of an existing feature or functionality.

Rules

• The change MUST NOT remove a feature partially or completely.
• The change MUST NOT remove a feature with or without a replacement.
• The change MUST NOT modify a default feature into an opt-in one.
• The change MUST modify an existing feature.
• The change MAY modify an existing default or opt-in feature.
• The change MAY modify an existing feature internally (e.g. refactoring).
• The change MAY modify an existing feature non-functionally.
• The change MAY require the attention of the user.

Add Feature — RELEASE

Definition

The addition of a new feature or functionality.

Rules

• The change MUST NOT remove, modify or replace an existing feature.
• The change MUST NOT be used by any existing feature.
• The change MUST NOT be a default feature.
• The change MUST be an opt-in feature.
• The change MAY extend an existing feature, but MUST be opt-in.
• The change SHOULD NOT require the attention of the user.