Versioning in 3D

Wow! Versioning in 3D, is there nothing safe from Hollywood producers? Well, yes. I am not referring to versioning while wearing those plastic glasses issued in cinemas everywhere, but to the three dimensions in which items are version controlled.

Version space

A system is composed of components (from now on I will assume we’re talking about software, so these components are files). Each file has a name that identifies is from the broader system space. Each file can exist in various variants (one for each operating system for example). And each variant can have a number of revisions, one derived from the previous by a developer making changes—I’m using ‘revision’ here to keep is distinct from the more general ‘version’ topic of this post; ‘revision’ and ‘version’ are often used interchangeably.

This seems like only two version dimension: variant and revision. However, when considering the version space of a system the identity becomes a significant part of the version as it locates the item in system space (e.g. it locates the item on the filesystem).

As the illustration below shows, unique versions of items are located in the three dimension. The grey box is version 1 of file1 and is suitable for the z/OS operating system.

file1 — identifies the item within the overall system space.

z/OS — identifies the variant.

1 — identifies the specific version of that variant.

Version 1 of file1 on the z/OS operating system

We may examine revision 3 of file1 and note that is has only Unix and z/OS variants.

Version 3 of file1 has only two variants

Or we may look at the Unix variant of file1 and note it has revisions 1, 2, and 3, while the z/OS variant has only revisions 1, and 2.

file1 variants

Or, if the revisions where baselines of the system, we can see that revision 1 contains file1 and file 2, with file1 in Unix and z/OS variants, but file2 in Unix, z/OS and Windows variants. In other words, file1 is not required in the Windows configuration of the system.

‘System’ revision 1

Do we need more dimensions?

The brief answer is no. It may seem that if we have more mutually exclusive variants that we need more dimensions in our version space

What if we had two configurations for our system, one optimised for speed and the other optimised to minimise memory footprint. We cannot select both because by optimising for speed we have to increase memory footprint, and vice versa. Does this not demand another version dimension? No, we have simply created compound variants; Unix/speed, Unix/memory, VMS/speed, VMS/memory, etc.

Each dimension represents a different ‘sort’ of selection criteria. Increasing the variant options simply increases the number of entries in the variant dimension. It does not create a new sort of selection, they remain variant selectors no matter how many we create.

The three dimensions of this version space represent:

  1. Composition—broad component identity, in this article, files.
  2. Function—the set of functional features to be selected for each component.
  3. Revision—the revision from a history of changes along the other dimensions.
About these ads
  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: