Project Life Cycle Guidelines

It should be known, why a project is created and under which conditions it will be dismantled.

The commit log is a program, that describes the development of the project. The semantic versioning is used as a default versioning format.

Prioritize a buildable and working project state at every point in the development. Prefer test driven development. Ensure that the project is build, tested and executed in different environments, in order to ensure, that the projects works.

Prefer that backwards compatibility is provided as good as planned.

Do not assume that better skills, more intelligence, working harder, etc. automatically lead to a better result.

Prefer every part of the development process having a task or goal.

If projects become big or mature enough, it should be considered to partition these into parts dedicated to certain overhaul aspects of the projects in relation to their environment. If projects are not big enough to be split up, it may help to consider every folder with source code as its own mini sub project.

One way of doing this, is to partition the project into layers, where the deepest parts ensure, that the core idea of the project works. Partitions on the outer layers are more and more concerned with the environment like dependencies:

  1. Core: the core contains the minimal implementation to get the project running.
  2. Merger: the merger establishes a common vocabulary and interface, for the core features of the project. It has the authority to define and verify every core feature of the project.
  3. Sheath: the sheath contains alternative implementations, plugins, extensions, etc. These are often used with project or are explicitly supported. It is often used to add external dependencies to the project, without polluting the core.
  4. Environment (Env): the environment is an dependency, software, alternative implementation or plugin, that is not explicitly supported. Such things may be absolute necessary to run the software, which is the case for operation systems, but they may also be perfectly integrated plugins, that were not published yet.

This is a nice metaphor, but is very uncommon in the public, so the following partitioning makes more sense in practice and should be used instead:

  1. Core: the core contains the minimal implementation to get the project running.
  2. API: establishes a common vocabulary and interface, for the core features of the project. It has the authority to define and verify every core feature of the project and therefore may contain the testsuite of the project.
  3. Extension (Ext): Contains alternative implementations, plugins, extensions, etc. for the project.
  4. Documentation (Doc): The doc contains documentation, media files and such and may be especially useful for user manuals and similar.