Design decision 6 - Versionning

Summary

Issue

The wet-boew version was always sequential but it was not always consistant with the type of changes introduced. That force implementer to do more extensive testing or/and analysing when updating their current WET-BOEW/GCWeb version.

Also, wet-boew product and gcweb theme don’t necessary evolve and get improvement the same way. Using the same version number for both product didn’t represented the reality of those product.

History

The wet-boew project and gcweb project hasn’t followed the semantic versioning. That means every release is potentially a minor release because it’s add functionality and even some release contains breaking changes.

Themes and the wet-boew share the same verioning number no matter the changes introduced.

Proposal

This design decision propose to follow semantic versioning 2.0 for all wet-boew centrally managed projects (including GCWeb/Canada.ca theme) and a variant for the wet-boew core project.

Semantic Versioning Summary

Given a version number Major.Minor.Patch, increment the:

  1. Major version number when you make incompatible API changes;
  2. Minor version number when you add a feature in a backwards-compatible manner; and
  3. Patch version number when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the Major.Minor.Patch format.

See the full version of the Semantic Versioning 2.0.0 document for more detailed information.

Semantic Versioning WET-BOEW product variant

This definition applies only to the product created from the sources: https://github.com/wet-boew/wet-boew and it is probably compatible with all other versions before v4.0.29.1 published under the identifier « 4.x »

This variant includes the addition of a numerical suffix in order to identify the product’s architectural version.

For example, version 4.0.29.1

Variant details of wet-boew versioning

Given version number Architecture.Major.Minor.Patch, increment the:

  1. Architecture version number when the internal API, such as plug-in interlacing, or the internal and external product integration methodology have non-backwards-compatible changes;
  2. Major version number when you make backwards-compatible feature changes;
  3. Minor version number when you add backwards-compatible features; and
  4. Patch version number when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the Architecture.Major.Minor.Patch format.

Semantic Versioning Specification Change (applicable only to WET-BOEW.Core)

In addition to the changes below, the rest of the specifications remains untouched.

Changes to provision 2 include the following:

  1. A normal version number Must be on A.X.Y.Z format, where A, X, Y, and Z are non-negative integers, and Must Not contain leading zeroes. A is the architectural version, X is the major version, Y is the minor version, and Z is the patch version. Each element Must increase numerically. For instance: 2.1.9.0 -> 2.1.10.0 -> 2.1.11.0 -> 3.0.0.1.

Provision 8-1 must be added after provision 8, and it should read as follows:

8-1. The architectural version identifier A (A.X.Y.Z A > 0) Must be incremented if non-backwards-compatible changes are introduced for plug-in interlacing or for internal and external product integration methodology. This May include at the same time major, minor, and patch changes. Major, minor, and patch version identifiers Must be set to zero when the architectural version identifier is incremented.

Public API

Each plug-in’s public API is defined by the design decision #3.

The WET-BOEW and GCWeb public API is defined as follows:

Ressource