Design decision 6 - Versionning
- Expert: @duboisp
- Status: Approved
- Type: Refine current practice
- Last updated: 2019-09-22
- (2019-09-22) Published
- (2019-09-20) Approved at the WET roadmap meeting
- (2019-08-21) Trivial editorial edits
- (2019-05-16) Presented at the WET roadmap meetings
- (2019-02-11) Initial draft and applied
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.
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.
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:
- Major version number when you make incompatible API changes;
- Minor version number when you add a feature in a backwards-compatible manner; and
- 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 v18.104.22.168 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 22.214.171.124
- Architecture: 4
- Major: 0
- Minor: 29
- Patch: 1
Variant details of wet-boew versioning
Given version number Architecture.Major.Minor.Patch, increment the:
- 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;
- Major version number when you make backwards-compatible feature changes;
- Minor version number when you add backwards-compatible features; and
- 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:
- 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: 126.96.36.199 -> 188.8.131.52 -> 184.108.40.206 -> 220.127.116.11.
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.
Each plug-in’s public API is defined by the design decision #3.
The WET-BOEW and GCWeb public API is defined as follows:
- Structural page labels (Template);
- Styles limited to CSS category names or HTML structure styles with their respective effect, regardless of their implementation;
- Plug-in interlacing defined by the list of functions and essential variables used by one or more plug-ins;
- The total plug-ins with their respective versions from which each plug-in is defined by:
- Configuration structure, as well as each property’s type of data;
- HTML labels representing templates for user interface design;
- Key information for plug-ins;
- Plug-in appearance and formatting (CSS); and
- Internationalised terms used (character strings) by the plug-in.
- Their templates, components, and variants are defined by:
- HTML labelling;
- Structure information;
- Components that in turn may include the same elements of a template;
- Appearance and formatting (CSS); and
- Internationalised terms used (character chains).