1. Home
  2. General functionalities
  3. Versioning and publishing

Versioning and publishing

When working on a complex AEC project, you will probably want to create and publish different versions of your model due course of the project. Below we will explain how to do this.

The versioning of projects is managed in the projects overview. In this example (click on image to enlarge), there is a working version (where data can be edited) and there are two static versions (“not published”) and one published version that is accessible for external project actors.

Different versions

In BriefBuilder, we make a distinction between four types of versions:

(1) Working version

This is the editable version of a project model. Typically, the data in this version are not yet formally approved and work-in-progress. Access tends to be limited to the project team, but that depends on how your project is organised.

When you create a new project, it will by default be in the working version modus.

(2) Static version

This is a ‘frozen’ version of your project model. You can see all the data (requirements, verifications, …), but you can longer edit any of it.

A crucial advantage of making static versions is that this allows you to compare different versions, which means that you can check how data has been modified over time (what has been added, deleted, changed?) by means of a version change report.

Especially when your project is a clone from a template project, it is recommended to start with making a static version so you can always track how your project deviates from the original template.

To make a static version of your model, do the following:

  • Go to projects overview
  • Click on the icon (“create a version of this project”)
  • Give the version name and/or number

(3) Published version

A published version is an ‘offical’ version of your project model. It is typically a version that you want to share with external actors (e.g. the contractor, the design team, …), as input for tender procedures, contractual agreements and/or the design and engineering process.

The published versions are visible for the role viewer – all published versions’. As the role’s name indicates, users with that role only get to see published versions when they log in.

To publish a version, you first make a static version and then put it on published:

  • Go to projects overview
  • Click on the icon (“create a version of this project”)
  • Give the version name and/or number
  • Click on the icon (“publish this version”)

If necessary, you can also unpublish a version. You can do so by clicking on the icon.

(4) Archived version

An archived version is a stored version that is lo longer editable, for which all account rights are revoked. You typically archive a project when it is completed and there is no longer a need to be able to edit the data.

A stored version is different from the aforementioned versions in the sense that you store the entire thing: the working version plus the static and published versions that are there.

To archive projects, click on the  icon in the project’s task bar.

Please note: you can easily restore an archived project at any time you want to. This can be done by clicking on the icon in the project’s task bar.

Summary

  EditableVisibility Prime purpose
Working version Yes For all roles except for “Viewer – published versions”   Editing data
Static version No For all roles except for “Viewer – published versions”   Being able to compare different versions at a later stage
Published version No For all roles To share formally approved project data with external parties  
Archived versionNoOnly for environment editors / adminstratorsStoring a project once it is finished

The distinction between these different versions follows the logic of the ISO 19650 standard for CDE’s (common data environments), which makes a distinction between information that is work-in-progress (‘working version’), shared (‘static version’), published (‘published version’) and archived (‘archived projects’).  

Possible workflow for working with versions (based on ISO 19650)

Naming and numbering

When creating different versions of your BriefBuilder models, you have think about how you to want to name the different versions.

As you will notice, the name field is fully flexible. We did this because every project and every organisation tends to have its own naming and numbering conventions.

When using version numbering, we recommend that you take the difference between static and publish versions into account.

Static versions tend to be for internal use, so these can best be numbered as 0.1, 0.2 etc. Officially published versions are ‘finished’ and can therefore have numbers like 1.0, 2.0 etc.

But, as said, feel free to use any system you like : – )

Updated on 25 August 2020

Was this article helpful?

Related Articles

Leave a Comment