Open bigdoods opened 7 years ago
Table included. Comments on how to make IFC4.1.0.3 as the prominent specification required.
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.
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:
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.