Versioning
Changes in WET-BOEW and GCWeb Version Monitoring
Effective on: February 11, 2019
- Version monitoring is done according to the Semantic Versioning
- The WET-BOEW project version number is slightly different, as defined by the Semantic Versioning, with the addition of a numerical suffix representing the architecture, as described below.
- The WET-BOEW version number is now independent from the GCWeb (Canada.ca) theme’s version number.
This new definition applies to the version and to all subsequent versions of:
- WET-BOEW, version 4.0.30
- GCWeb (Canada.ca), version 5.0
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 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
- Architecture: 4
- Major: 0
- Minor: 29
- Patch: 1
See this variant’s details.
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:
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:
- 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:
- JavaScript functions;
- 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).
Versioning prior version 4.0.29.1
Major version (e.g, v3.1.x to v4.0.0)
- Typical risk of things breaking: High
- Typical effort to upgrade: High
- Typical changes:
- Major framework changes (including major breaking changes)
- Major markup changes (including major breaking changes)
- New features and enhancements
- Bug fixes
- Typical actions required to upgrade:
- Modify existing content and code new content differently
- Major markup changes
- Add and replace JS, CSS and image files
Minor version (e.g., v3.0.x to v3.1.0)
- Typical risk of things breaking: Moderate
- Typical effort to upgrade: Moderate
- Typical changes:
- Minor framework changes (possibility of minor breaking changes)
- Minor markup changes (possibility of minor breaking changes)
- New features and enhancements
- Bug fixes
- Typical actions required to upgrade:
- Minor markup changes
- Add and replace JS, CSS and image files
Maintenance version (e.g., v3.1.0 to v3.1.1)
- Typical risk of things breaking: Low
- Typical effort to upgrade: Low
- Typical changes:
- Minor enhancements
- Bug fixes
- Typical actions required to upgrade:
- Add and replace JS, CSS and image files
- Date modified: