ISO 19650 Work in Progress (WIP) Revisions with Semantic Versioning: A Case for Simplicity in BIM File Management

Why the ISO 19650 WIP Process Feels Counter-Intuitive

Managing versions of documents, models, and files in the construction industry - especially in the context of BIM (Building Information Modelling) - is essential for keeping projects on track. The ISO 19650 framework provides a structured system for version control, but when it comes to managing Work In Progress (WIP) revisions, many professionals find the process counterintuitive, particularly when compared to more fluid versioning systems, such as semantic versioning commonly used in software development.

Let’s explain why the ISO 19650 WIP process feels awkward and how it could be improved by aligning it more closely with semantic versioning principles.

ISO 19650’s Work In Progress (WIP) Revision Structure

In the ISO 19650 framework, the versioning of files during the WIP stage follows this pattern:

P01.01 → P01.02 → P01.03 → P01 → P02.01 → P02.02 → P02

In this system:

• P01.01, P01.02, P01.03 represent incremental updates in the WIP phase of the major (primary) revision P01.
• Once P01 (the first published revision) is ready, it is locked in, and subsequent changes begin a new WIP sequence with P02.01, P02.02, and so on, leading up to P02 (the next published version).

This structure is logical in theory but can be confusing in practice, especially when managing large projects where many revisions occur across multiple versions.

Why the ISO 19650 WIP Process Feels Counter-Intuitive

In the ISO 19650 framework, the Work In Progress (WIP) revision system works by incrementing changes within the same major version. For instance, if you start with P01, the system tracks incremental changes as P01.01, P01.02, P01.03, and so on. Once the file is published as P01 (the final version for that stage), any further revisions are tracked under a new major version, starting with P02.01.

Sorting Issue

When these versions are included in file names and sorted alphanumerically (as they often are in file systems or cloud storage), the ISO 19650 system can create confusion. For instance:

• P02 (the published version) may be sorted before P02.01, P02.02, etc., because alphanumerically, "P02" comes before "P02.01".
• This sorting order is problematic because P02 is actually the latest major version, but it appears earlier in the list than its subsequent WIP revisions.

To give a practical example, consider a file explorer displaying the following:

• P01
• P01.01
• P01.02
• P01.03
• P02
• P02.01
• P02.02

Here, P02 (the published version) appears before P02.01 and P02.02, even though those are later revisions. This disrupts the logical progression and makes it difficult to track the actual latest state of the file.

Semantic Versioning as an Intuitive Contrast

Now, compare this with semantic versioning, which provides a more natural and continuous flow in versioning. In semantic versioning, the structure is Major.Minor.Patch (e.g., v21.1.2), where:

• Major versions indicate large, breaking changes.
• Minor versions indicate new features or additions.
• Patch versions indicate bug fixes or small updates.

In semantic versioning, there’s no "reset" between major versions. Instead, the numbering follows a clear, logical progression that builds on the previous version. For example:

• v21.0.1 → v21.0.2 → v21.1.0 → v22.0.0.

In this system, each version naturally builds on the previous one without resetting. More importantly, when files are sorted alphanumerically, the sorting order follows the progression of changes. If we were to apply this logic to the ISO 19650 system, the versions would flow something like:

• P00.01 → P00.02 → P01 → P01.01 → P01.02 → P02 → P02.01 → P02.02.

This structure ensures that major versions (e.g., P02) appear after earlier major versions (e.g., P01), and all subsequent minor and patch updates (e.g., P02.01, P02.02) appear after their respective major versions. This would allow for proper sorting and a clear progression that is easy to follow.

The Contrast: Why Semantic Versioning Feels More Intuitive

1. No Reset in Minor Versions: In semantic versioning, when you move from one major version to another (e.g., from v21 to v22), the minor and patch numbers continue incrementing logically. There’s no need to reset, making it easy to track the evolution of the file.
2. Logical Sorting: Since semantic versioning uses a continuous numbering system, files are naturally sorted in the correct order when viewed in file explorers. The latest version (e.g., v22) always appears after earlier versions (e.g., v21), and sub-versions (e.g., v22.1) appear in sequence as expected.
3. Clear Version History: The progression in semantic versioning creates a clearer sense of how files have evolved over time. Each step in the version history builds on the last, without disrupting the flow or creating confusion with resets.

Applying Semantic Versioning in Construction (BIM)

In contrast to ISO 19650’s revision system, semantic versioning, widely used in software development, offers a much more intuitive flow.

Applying this principle to BIM and Revit families could look like this:

• Major Version: The major version number could represent the Revit year version (e.g., 21 for Revit 2021).
• Minor Version: Incremented when new features are added, such as new parameters, nested families, or 3D elements.
• Patch Version: Incremented when bug fixes or minor adjustments are made, such as updating existing parameters or tweaking family elements.

Example Using Semantic Versioning

• PD_ELF_Outlet-Power-Double_v21.1.2: This file name represents a Revit family:v21: The file is built in Revit 2021.1: One minor change has been made, such as adding new parameters.2: Two bug fixes or minor updates have been applied to the family.

This versioning system is intuitive because each number incrementally builds on the previous one, without resets or backtracking.

The Benefits of Semantic Versioning Approach

• Intuitive Workflow: By aligning the WIP process with semantic versioning, versioning becomes more intuitive. Teams can follow the incremental progression of changes without confusion or unnecessary resets.
• Better Sorting: File management systems will sort files in the correct order without issue, as the numbering flows naturally.
• Easier Collaboration: Teams working across disciplines (architects, engineers, contractors) will have an easier time tracking revisions and ensuring they’re working with the correct version.
• Consistency Across Tools: Many software tools, such as Revit or Navisworks, are already designed to handle semantic versioning, making this approach more compatible with the digital tools used in construction.

Conclusion: A Case for a More Intuitive Versioning System

While ISO 19650 provides a structured approach to managing WIP revisions, its system can feel counter-intuitive and disjointed, especially when compared to the more natural flow of semantic versioning. By adopting a versioning system that follows semantic versioning principles, we can make file management in construction projects more intuitive, reduce errors, and ensure smoother collaboration across teams.

What do you think? Should the construction industry adopt a more semantic approach to file versioning? How do you manage WIP revisions in your projects?