Versioning

Changes in WET-BOEW and GCWeb Version Monitoring

Effective on: February 11, 2019

This new definition applies to the version and to all subsequent versions of:

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

See this variant’s details.

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:

2. 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:

Versioning prior version 4.0.29.1

Major version (e.g, v3.1.x to v4.0.0)

Minor version (e.g., v3.0.x to v3.1.0)

Maintenance version (e.g., v3.1.0 to v3.1.1)

Date modified: