Design decision 3 - WET API/Blueprint



There is no or only a vague guidance on how versioning should be applied. There is no official information defining how an element or a function in the WET core or in a WET feature should be evaluated in order know the actual changes introduced by a PR (pull request) would have a major, minor, trivial impact on the feature and the project overhaul.

The current versioning convention used in WET are not very helpful other than being sequential. Some trivial/patch release also introduce some non-documented breaking change.

Propose solution

Use semantic versioning 2.0 for WET. However in order to following it, it require to define what we consider to be the API of our product.

A WET feature has multiple facet/component which is not limited to the API (Application Programming Interface). The design pattern specified by the plugin, the layout, how it can be configured should be an integral part of the WET feature versioning. All those multiple versioned facet are defined as the WET feature blueprint.

When the terminology “WET feature blueprint” is interpreted against the semantic versioning 2.0, it represent the same as the “public API”.

Blueprint need to be documented and monitored. A non official documented blueprint for a given WET release are considered out of scope and should be considered like an experimental feature that is at risk to change.

A working example aren’t implicitly part of the blueprint of a WET feature.

WET feature blueprint

The following are the blueprint component for a given WET feature:

For one WET feature, multiple variation may exist for one blueprint component.

Next step