Naming and Identification
Main > Organization > Standards > Nomenclature and Taxonomy
Contents
Overview
This page describes the (proposal to) the GVCS naming / identification scheme. The goal of this scheme is to identify modules and machines at a precise version unambiguously.
Background
Just like in software development, GVCS machines depend on each other. The analogy goes like this: A software typically depends on a few (external) libraries at specific versions. Next, the software changes or some of the libraries change, or both. You need to keep track of that very carefully, because if you mistype one letter in the interface (= "misplace one screw hole by half an inch"), nothing works anymore. In order to master this problem, you need to fulfill these requirements: Identification, Workflow, Tools.
Example for naming convention
The following, fictitious example shows the naming convention in action:
Identification
In order to uniquely identify a machine/module at a certain state, we find that machine/module names are not enough.
We use the following convention: moduleID, version, where:
- moduleID: A unique number as defined in the Master Index. Once assigned, this number never changes.
- version: The module version is a simple number, preceded by a "v".
v1, v2, v3, .... Do not use any other version tags (v3.2 or 4beta).
Master Index
Main article: Master Index
In order to have a central reference point for unique IDs, versions and dependencies, a Master Index is proposed. This may be any sort of database which stores the following three types of data: Modules, Versions, Dependencies.
In more details, these descriptions may look as follows:
[module] What is moduleID 01?
- moduleID: 01
- name: CEB Press
- alias: The Liberator, Compressed Earth Brick Press
- description: ...
[version] What is the latest version of moduleID 01?
- version: v6
- date: 2014-08-27
- by: John
- description: ...
[dependency] What does moduleID 01, v6 depend on?
- moduleID: 119, version: v2 ("Grate")
- moduleID: 121, version: v4 ("Shaker")
- moduleID: 110, version: v1 ("Core Assembly")
Workflow
Many people develop collaboratively and add ideas and changes. On the other hand, only the responsible person for the machine/module is allowed to update it's version number. By that, this person guarantees that everything below in the dependency tree works together.
Tools
The current OSE documentation hierarchy works like this (example):
OSE main page: Machine Index > CEB Press Dozuki: CEB Press > Modules > Frame > Wiki: Development Board > Exploded_Parts_Diagram (PDF).
