From Open Source Ecology
Jump to: navigation, search


Versioning is part of OSE's Taxonomy. The taxonomy allows for a logical organization of all content on this Wiki. Pending understanding of the taxonomy and Module Based Design, an unlimited number of contributors could work in parallel towards OSE's goal of creating an Open Source Economy.


Versioning practice at OSE follows the naming convention of naming the module under development followed by v for version and date. Example:


This refers to the 3D Printer, the version whose start build date was October of 2019.


  1. Use a unique name for everything. For example, 3D Printer v19.10 - is not the same as 3D Printer v18.09.
  2. When a new version is created, add that version to the list at the Genealogies page.
  3. Use a version at every level - Machine, Module, or Submodule/Part. Note that these different levels of detail are all considered as modules when referring to the development process: you can be developing the final product at the machine level, at the module level, or sub/part level. Each of these modules should have a version.
  4. When developing at the Module level, include the full name that identifies the largest unit of organization: for example: use 3D Printer Extruder v19.10, not Extruder v19.10. Same for part - use the 3D Printer Extruder Nozzle v19.10, not Nozzle v19.10.
  5. Use official naming convention of modules from GVCS Modules List.
  6. In name, use capital letters for all first letters of words in the name. Thus, it's 3D Printer, not 3D printer.
  7. Use v in small letters, which is short for version
  8. Since we go through multiple prototypes over multiple years - start with the year in the version name.
  9. Use month for the month the projects was STARTED. Since documentation is realtime and you don't know when the version development will end - it makes sense to use the month started.
  10. If multiple versions are iterated in the same month, name the latter one with the DAY it was started, such as v19.10.22 (for starting on October 22)


Software people favor the dot number convention (Semantic Versioning) v1.0, v1.1, v1.1.1 etc. This can be used, but OSE favors the more transparent date-based notation - which includes a sense of project management for overall project completion according to the Critical Path and Product Ecology - involving the 2028 finish date. Knowing which versions are being worked at the same time provides immediate information (by virtue of version date in the name) on project activity for purposes of coordination with large parallel teams.

Semantic Versioning solves for a different thing in software. In software, you can get to examples like: version 1.0.0-x.7.z.92. In hardware, you have 100x the documentation requirement because hardware requires about 100x-1000x more data to keep track of. In summary: that is very hard or impossible. The Semantic Versioning system applies only to simple documentation, and a more complex form, where granular breakdown is not explicitly documented, but instead taken from former versions, is required in hardware. In summary: software can be documented rigorously. Hardware cannot be, because it's too complex. For example, you will not catch an artifact such as, this student in Djibouti used to much grease on a bolt. Point: you don't document everything. So a system of a different nature is required for hardware, and that's what the OSE system, summarized in OSE Development Protocol, embodies.

We can use semantic versioning for OSE software. But it's not a good idea to use semantic versioning for OSE hardware.

This makes no sense in hardware, because it's impossible to implement! Note that OSE documentation is comprehensive for machines. All known information is stored under the Template:Dev (20 items), Template:Enterprise - and these are the short versions for a total of 40 items in the short version and 100 overall. For each version, you have to keep track of 100 items, not just 1 like in software. So to have 100 pages for 1.0.0-x.7.z.92 is impossible. So what we do, is we make some documentation implicit. For example, if something is undocumented, one can check former versions in the Genealogy to see what came before.

To super-summarize: the problem statements are different in hardware and software because of the fundamental nature of the difference. Hardware has no uniform compiler! If you can understand this point, then I believe that the call for semantic versioning of hardware goes away. Put in another way - Semantic Versioning solves for dependency hell. In hardware, each build is a new creation, and therefore, the concept of dependency hell does not arise! So put in another way: OSE says yes to semantic versioning only if there were no real builds! MJ.