Versions, Variants & the rest – Basic Definitions
by Danilo Beuche
Versions and variants: know the difference
When talking about product line engineering and variant management, it is important to share a common understanding of the basic terms. Over the years, I learned that the distinction between "version" and "variant" is one of the most challenging ones, because in many contexts outside of product line engineering (PLE), those terms are used more or less interchangeably. That’s one of the reasons why we often get visitors to our trade show booths saying something like "I see you are doing some kind of version management. What are you doing differently compared to <insert name of favourite version control system here>".
Actually, quite a lot, because we are not doing version management at all. In this article, I will give some basic definitions for the relevant terms related to versions and variants as I use them. I will also illustrate how those terms are related and explain why they often are seen as describing the same thing.
Defining the basic terms
Version
A version of an asset is the recorded state / content of that asset at a given point in time. Two versions of an asset may represent identical or different content of that asset. Consequently, versions reflect the same asset at different points in time. In most cases, versions are identified by some labels or numbers. In some cases, a distinction is made between a revision (created whenever an asset changes) and a version (referring to a labelled/named revision).
Baseline
A baseline refers to a (named) snapshot of versions of a set of assets.
Variation
A variation is a difference between two comparable (sets of) assets. Imagine there’s a product with an enclosure made from either metal or plastic, then "metal enclosure" and "plastic enclosure" are the two variations of the product’s enclosure.
Variation point
A variation point represents a decision that leads to different variants of an asset. A variation point consists of a set of possible instantiations (legal variations of the variation point). Taking the product with either metal or plastic enclosure as an example again, the variation point would be the "enclosure material", and the corresponding variations would be "metal enclosure" and "plastic enclosure". A variation point usually specifies the binding times, that is, the time/times at which a decision about the instantiation has to be taken. Examples for binding times are compile time, installation time, or runtime.
Variant derivation
Variant derivation is the action which takes the set of available assets as input, combines them and binds/instantiates the variation points within. If there are variation points with multiple binding times, derivation will happen in multiple steps, one step per binding time. The result of derivation is a set of derived assets. On a technical level, derivation can be executed in many ways. The simplest (and least recommend) way is to copy assets and modify them manually (e.g. by specifying configuration parameters). The result of derivation is often called a configuration.
Derivation is a central part of product line engineering, because changing one product line asset (for example when fixing a bug) often requires the recreation of all derived products that include the changed asset. To minimize the effort of recreating the derived products, derivation is often automated in a tool.
Variant
An asset X’ constitutes a variant if it has been derived from an asset X and has properties that are relevant to a stakeholder which make X’ different from other variants derived from the same asset X.
For example, if a machine can produce blue and red (and otherwise identical) balls by coating a ball with blue or red paint, it is able to create two variants (blue ball, red ball). The actual number of balls coated blue or red is irrelevant. Whether it’s one in blue and one in red or 100 in blue and 200 in red, the number of variants is always two.
If you’ve read carefully, you will note that the definition of the term variant does not talk about the time when the derivation happens. This is intentional: The notion of a variant is independent from time. Whether the variants are created at the same time or months apart, it doesn’t matter.
It is important to understand that not every small difference between two assets creates a variant; what matters is whether the involved stakeholders see a relevant variation. Imagine you buy two shirts, one today, and another one next week. Same brand, same colour, same cut, same size. Still, these shirts could have different washing labels, because the manufacturer changed the label in the meantime. Nevertheless, you, the stakeholder, will treat these shirts as equal, because the difference in washing labels doesn’t play a role for you. Now imagine a different situation: You buy one shirt for yourself and the second one for another person in a different size. In this situation, the shirt size is a relevant difference, and for this reason, you will consider the two shirts as variants of each other.
Variability
Last but not least, variability describes the possible variations of assets with variation points. Since listing all possible variants is usually impossible due to the huge number of potential variants, the variability of a systems is often described with the help of variability models such as feature models or configuration rules.
Summing up
Hopefully, these definitions have made it a little clearer how variants and versions are different and why the difference matters in product line engineering. If you want to know more, have a look at our other articles or browse our glossary.
About the author
Prof. Dr. Danilo Beuche is co-founder and CEO of pure-systems and one of the leading minds in Product Line Engineering (PLE). Danilo is driven by the idea of helping companies to develop better, longer-lasting products while always paying attention to economic reuse and sustainability. In 2001, he co-founded pure-systems, a software company specialized in services and tool development for the application of product line technologies in embedded software systems. As the market leader in PLE, pure-systems helps global enterprises and medium-sized companies to keep costs low while improving the quality and safety of their products.
Before founding pure-systems, Danilo worked on tool support for feature-based software development at the University of Magdeburg. Since 2016 he is also an Honorary Professor at the Information Systems Institute (IWI) of Leipzig University.