IFC naming strategy in the Reference section

[bigdoods]

The naming strategy used by the IFC project can be confusing for people looking to access documentation. For example: IFC4x1 supersedes IFC4_Add2. To the non-domain expert, there is no immediate logical way to draw this conclusion. This presents a challenge when users are looking for the 'latest' version.

BuildingSMART use an alternative system which promotes the use of semantic versioning as a point of reference for each schema.

See Tim Chipman's explanation below:

Following is a proposal to consolidate messaging around IFC versioning to make it more clear to
software vendors on which standards they should target and maintain. Historically, IFC has had major
“platform versions” such as IFC2x, and now IFC4x, where the “core” remains stable meanwhile
“extension versions” such as IFC2x2 and IFC2x3 provide additive capabilities without impacting this core.
Then there have also been “addendums” containing minor schema changes and documentation updates
such as IFC4 Addendum and IFC4 Addendum 2. Then there has been the case of a “technical
corrigendum” such as IFC2x3 TC1 which update documentation but do not impact the schema.
Meanwhile, during development there have been interim versions called “release candidates” if they
are deemed suitable for vendors to implement, “beta” if they are deemed suitable for external review,
and “alpha” if they are deemed intended for internal review. The table below summarizes IFC releases
to date (though excluding IFC4 development releases). Each release may be shown as a normalized
version number and/or using existing notation (e.g. 4.0.2.0 for IFC4.0 Addendum 2).

Thus, it is advised that we provide a conversion table at the top of the reference page which explains to a user the conversion between specification and the common community name. For example 'IFC4_Add2' will be referred to as '4.0.2.0', which is what it will be referred to throughout the documentation.

[bigdoods]

Table included. Comments on how to make IFC4.1.0.3 as the prominent specification required.

[klacol]

A semantic versioning system is nice. (see here: http://semver.org). We would have to define the three levels for IFC.

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Version name: IFC4_Add2
Version: 4.0.2.0 (without IFC prefix)
Name in Texts: IFC 4.0.2.0 (With IFC and space)

MAJOR: 4.0
MINOR: 2
PATCH: 0

I propose to use all three parts for every version, even if the patch is zero.