---
{
	"title": "Versioning",
	"language": "en",
	"description": "Versioning - Version history - Web Experience Toolkit (WET)",
	"altLangPrefix": "version-info",
	"dateModified": "2019-02-11"
}
---

<section class="alert alert-info">
	<h2>Changes in WET-BOEW and GCWeb Version Monitoring</h2>
	<p><strong>Effective on:</strong> February 11, 2019</p>
	<ul>
		<li>Version monitoring is done according to the <a href="https://semver.org/">Semantic Versioning</a></li>
		<li>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.</li>
		<li>The WET-BOEW version number is now independent from the GCWeb (Canada.ca) theme&rsquo;s version number.</li>
	</ul>
	<p>This new definition applies to the version and to all subsequent versions of:</p>
	<ul>
		<li>WET-BOEW, version&nbsp;4.0.30</li>
		<li>GCWeb (Canada.ca), version&nbsp;5.0</li>
	</ul>
</section>
	<h2>Semantic Versioning Summary</h2>
<div class="well well-lg">
	<p>Given a version number <strong>Major.Minor.Patch</strong>, increment the:</p>
	<ol>
		<li><strong>Major</strong> version number when you make incompatible API changes;</li>
		<li><strong>Minor</strong> version number when you add a feature in a backwards-compatible manner; and</li>
		<li><strong>Patch</strong> version number when you make backwards compatible bug fixes.</li>
	</ol>
	<p>Additional labels for pre-release and build metadata are available as extensions to the <strong>Major.Minor.Patch</strong> format.</p>
</div>
<p>See the full version of the <a href="https://semver.org/">Semantic Versioning 2.0.0</a> document for more detailed information.</p>
<h3>Semantic Versioning WET-BOEW product variant</h3>
<p>This definition applies only to the product created from the sources: <a href="https://github.com/wet-boew/wet-boew">https://github.com/wet-boew/wet-boew</a> and it is probably compatible with all other versions before v4.0.29.1 published under the identifier&nbsp;«&nbsp;4.x&nbsp;»</p>
<p>This variant includes the addition of a numerical suffix in order to identify the product&rsquo;s architectural version.</p>
<p>For example, version&nbsp;4.0.29.1</p>
<ul>
	<li><strong>Architecture:</strong> 4</li>
	<li><strong>Major:</strong> 0</li>
	<li><strong>Minor:</strong> 29</li>
	<li><strong>Patch:</strong> 1</li>
</ul>
<details>
	<summary>See this variant&rsquo;s details.</summary>
	<p>Given version number <strong>Architecture.Major.Minor.Patch</strong>, increment the:</p>
	<ol>
		<li><strong>Architecture</strong> version number when the internal API, such as plug-in interlacing, or the internal and external product integration methodology have non-backwards-compatible changes;</li>
		<li><strong>Major</strong> version number when you make backwards-compatible feature changes;</li>
		<li><strong>Minor</strong> version number when you add backwards-compatible features; and</li>
		<li><strong>Patch</strong> version number when you make backwards-compatible bug fixes.</li>
	</ol>
	<p>Additional labels for pre-release and build metadata are available as extensions to the Architecture.Major.Minor.Patch format.</p>
	<section class="well">
		<h4>Semantic Versioning Specification Change (applicable only to WET-BOEW.Core)</h4>
		<p>In addition to the changes below, the rest of the specifications remains	untouched.</p>
		<p>Changes to provision&nbsp;2 include the following:</p>
		<div class="well">
			<p>2. A normal version number <strong>Must</strong> be on <strong>A.X.Y.Z </strong>format, where <strong>A</strong>, <strong>X</strong>, <strong>Y</strong>, and <strong>Z</strong> are non-negative integers, and <strong>Must Not</strong> contain leading zeroes. <strong>A</strong> is the architectural version, <strong>X</strong> is	the major version, <strong>Y</strong> is the minor version, and <strong>Z</strong> is the patch version. Each element <strong>Must</strong> increase numerically. For instance: 2.1.9.0 -&gt; 2.1.10.0 -&gt; 2.1.11.0 -&gt; 3.0.0.1.</p>
		</div>
		<p>Provision&nbsp;8-1 must be added after provision&nbsp;8, and it should read as follows:</p>
		<div class="well">
			<p>8-1. The architectural version identifier A (A.X.Y.Z | A &gt; 0) <strong>Must</strong> be incremented if non-backwards-compatible changes are introduced for plug-in interlacing or for internal and external product integration methodology. This <strong>May</strong> include at the same time major, minor, and patch changes. Major, minor, and	patch version identifiers <strong>Must</strong> be set to zero when the architectural version identifier is incremented.</p>
		</div>
	</section>
</details>
<h2>Public API</h2>
<p>Each	plug-in&rsquo;s public API is defined by the <a href="https://wet-boew.github.io/wet-boew-documentation/decision/3.html">design decision #3</a>.</p>
<p>The WET-BOEW and GCWeb public API is defined as follows:</p>
<ul>
	<li>Structural page labels (Template);</li>
	<li>Styles limited to CSS category names or HTML structure styles with their respective effect, regardless of their implementation;</li>
	<li>Plug-in interlacing defined by the list of functions and essential variables used by one or more plug-ins;</li>
	<li>The total plug-ins with their respective versions from which each plug-in is defined by:
	<ul>
		<li>JavaScript functions;</li>
		<li>Configuration structure, as well as each property&rsquo;s type of data;</li>
		<li>HTML labels representing templates for user interface design;</li>
		<li>Key information for plug-ins;</li>
		<li>Plug-in appearance and formatting (CSS); and</li>
		<li>Internationalised terms used (character strings) by the plug-in.</li>
		</ul></li>
	<li>Their templates, components, and variants are defined by:
	<ul>
		<li>HTML labelling;</li>
		<li>Structure information;</li>
		<li>Components that in turn may include the same elements of a template;</li>
		<li>Appearance and formatting (CSS); and</li>
		<li>Internationalised terms used (character chains).</li>
		</ul></li>
</ul>
<section>
	<h2>Versioning prior version 4.0.29.1</h2>
	<h3>Major version (e.g, v3.1.x to v4.0.0)</h3>
	<ul>
		<li>Typical risk of things breaking: <strong>High</strong></li>
		<li>Typical effort to upgrade: <strong>High</strong></li>
		<li>Typical changes:
			<ul>
				<li>Major framework changes (including major breaking changes)</li>
				<li>Major markup changes (including major breaking changes)</li>
				<li>New features and enhancements</li>
				<li>Bug fixes</li>
			</ul>
		</li>
		<li>Typical actions required to upgrade:
			<ul>
				<li>Modify existing content and code new content differently</li>
				<li>Major markup changes</li>
				<li>Add and replace JS, CSS and image files</li>
			</ul>
		</li>
	</ul>
	<h3>Minor version (e.g., v3.0.x to v3.1.0)</h3>
	<ul>
		<li>Typical risk of things breaking: <strong>Moderate</strong></li>
		<li>Typical effort to upgrade: <strong>Moderate</strong></li>
		<li>Typical changes:
			<ul>
				<li>Minor framework changes (possibility of minor breaking changes)</li>
				<li>Minor markup changes (possibility of minor breaking changes)</li>
				<li>New features and enhancements</li>
				<li>Bug fixes</li>
			</ul>
		</li>
		<li>Typical actions required to upgrade:
			<ul>
				<li>Minor markup changes</li>
				<li>Add and replace JS, CSS and image files</li>
			</ul>
		</li>
	</ul>
	<h3>Maintenance version (e.g., v3.1.0 to v3.1.1)</h3>
	<ul>
		<li>Typical risk of things breaking: <strong>Low</strong></li>
		<li>Typical effort to upgrade: <strong>Low</strong></li>
		<li>Typical changes:
			<ul>
				<li>Minor enhancements</li>
				<li>Bug fixes</li>
			</ul>
		</li>
		<li>Typical actions required to upgrade:
			<ul>
				<li>Add and replace JS, CSS and image files</li>
			</ul>
		</li>
	</ul>
</section>
