Naming and Identification: Difference between revisions

From Open Source Ecology
Jump to navigation Jump to search
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Overview ==
{{Breadcrumb|Organization|Standards|Nomenclature and Taxonomy}}
 
= 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.
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 ==
= 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.
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 ==
= Example for naming convention =
The following, fictitious example shows the naming convention in action:
The following, fictitious example shows the naming convention in action:


Line 13: Line 15:
[https://docs.google.com/drawings/d/13kZQvjosUuLp4NEqyZh6lHIqJStpwYNiHWWXUVO2dxw/edit edit]
[https://docs.google.com/drawings/d/13kZQvjosUuLp4NEqyZh6lHIqJStpwYNiHWWXUVO2dxw/edit edit]


== Identification ==
= Identification =


In order to uniquely identify a machine/module at a certain state, we find that machine/module names are not enough.
In order to uniquely identify a machine/module at a certain state, we find that machine/module names are not enough.
Line 21: Line 23:
* '''version''': The module version is a simple number, preceded by a "v". <code>v1, v2, v3, ...</code>. Do not use any other version tags (v3.2 or 4beta).
* '''version''': The module version is a simple number, preceded by a "v". <code>v1, v2, v3, ...</code>. Do not use any other version tags (v3.2 or 4beta).


In more details, the module and version descriptions may look as follows:
== 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:


<pre>
<pre>
Line 37: Line 44:


[dependency] What does moduleID 01, v6 depend on?
[dependency] What does moduleID 01, v6 depend on?
   - moduleID: 119
   - moduleID: 119, version: v2 ("Grate")
   - version: v2
   - moduleID: 121, version: v4 ("Shaker")
  - moduleID: 110, version: v1 ("Core Assembly")
</pre>
</pre>


== Workflow ==
= 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.  
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 ==
= Tools =


The current OSE documentation hierarchy works like this (example):
The current OSE documentation hierarchy works like this (example):
Line 51: Line 59:
[http://opensourceecology.org/gvcs/gvcs-machine-index/ OSE main page: Machine Index] > [http://opensourceecology.org/portfolio/ceb-press/ CEB Press]
[http://opensourceecology.org/gvcs/gvcs-machine-index/ OSE main page: Machine Index] > [http://opensourceecology.org/portfolio/ceb-press/ CEB Press]
[http://opensourceecology.dozuki.com/c/CEB_Press Dozuki: CEB Press] > [http://opensourceecology.dozuki.com/c/CEB_Press_-_Modules Modules] > [http://opensourceecology.dozuki.com/c/Frame Frame] > [[CEB_Press_6_-_Frame_-_Development_Board| Wiki: Development Board]] > [[CEB_Press_6_-_Frame_Module_-_Exploded_Parts_Diagram|Exploded_Parts_Diagram (PDF)]].
[http://opensourceecology.dozuki.com/c/CEB_Press Dozuki: CEB Press] > [http://opensourceecology.dozuki.com/c/CEB_Press_-_Modules Modules] > [http://opensourceecology.dozuki.com/c/Frame Frame] > [[CEB_Press_6_-_Frame_-_Development_Board| Wiki: Development Board]] > [[CEB_Press_6_-_Frame_Module_-_Exploded_Parts_Diagram|Exploded_Parts_Diagram (PDF)]].
=Links=
*[[OSE Serial Numbers]]
*[[Log Naming Convention]]
*[[Machine Naming Convention]]
*[[OSE Part Naming Convention]]

Latest revision as of 20:55, 23 October 2017

Main > Organization > Standards > Nomenclature and Taxonomy

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:

edit

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).

Links

Retrieved from "https://wiki.opensourceecology.org/index.php?title=Naming_and_Identification&oldid=160669"