[skip ci] update docs/README and add Release docs

docs/README.md

@@ -1,32 +1,6 @@
 This repository holds the documentation of the provs framework.
 
-# Provs framework
+# Design principles
-
-Provs is an easy-to-use provisioning framework for automating shell-commands or other tasks for provisioning reasons and other purposes.
-
-It combines 
-* convenience and robustness of a modern programming language
-* the power of shell commands 
-* clear and detailed result summary of the built-in execution handling 
-
-The provs framework consists of several layers. The most important are
-* provs-core
-* provs-ubuntu
-* provs-ubuntu-extensions
-
-### Write once, run everywhere
-
-Tasks can be run
-
-* locally
-* remotely
-* in a local docker container
-* and also in a remote container
-  
-Besides, it is possible to define a custom processor.
-
-
-## Usage
 
 For usage examples it is recommended to have a look at [provs-scripts](https://gitlab.com/domaindrivenarchitecture/provs-scripts) or [provs-ubuntu-extensions](https://gitlab.com/domaindrivenarchitecture/provs-ubuntu-extensions).
 
@@ -49,26 +23,24 @@ Idempotence means that you can run the same function once or several times witho
 However, there are cases where you don't want strict idempotence. E.g. if you are installing a program or cloning a git repo a second time, you might want to get just the latest version,
 even if an older version has already been installed earlier. This behavior is also known as quasi-idempotence. 
 The provs framework uses quasi-idempotence where "real" idempotence is not possible or does not make sense.
-For example, if you invoke "gitClone" a second time for the same repo, it will perform a "git pull" in order to retrieve the latest version of the repo. 
+
-Note, that git itself would throw an error if you would attempt to clone a repository twice.
+In the following document we describe how we implement idempotence: 
+
+https://gitlab.com/domaindrivenarchitecture/overview/-/blob/master/adr-provs/quasi-idempotence.md
 
 
 ## Architecture
 
-Multiple layers provide different levels of functionality:
+Multiple architectural layers provide different levels of functionality:
 
 ![provs layers](resources/provs-architecture-7.png "Provs architecture")
 
 
 ## Module structure
 
-![resources/provs-module-structure-4.png](resources/provs-module-structure-4.png)
+For the modules we use domain-drive design according to:
 
-Explanation:
+https://gitlab.com/domaindrivenarchitecture/overview/-/blob/master/adr-provs/ddd-structure.md
-* **Convention**: contains at least one function that provides the main functionality of this module.
-* **Base**: contains functions that provide more low-level functionalities of this module.
-
-About the dependencies have a look at the explanations in the chapter below.
 
 ## Module dependencies
 
@@ -79,22 +51,22 @@ __Explanation__:
 Modules:
 
 <ol type="A">
-  <li>Common module: has both a convention layer and a base layer</li>
+  <li>Common module: has both a domain layer and an infrastructure layer</li>
-  <li>Module with only convention layer: e.g. for very simple logic where no base layer is needed</li>
+  <li>Module with only domain layer: e.g. for very simple logic where no infrastructure layer is needed</li>
-  <li>Module with only base layer: these are often _utility modules_, which provide a collection of utility functions</li>
+  <li>Module with only infrastructure layer: these are often _utility modules_, which provide a collection of utility functions</li>
 </ol>
 
 Dependencies:
 
-1. Convention layer calls (a function in) the base layer of the same module
+1. Domain layer calls (a function in) the infrastructure layer of the same module
     * _Common practice of dependencies within a module_
-1. Convention layer calls (a function in) the convention layer another module
+1. Domain layer calls (a function in) the domain layer another module
     * _Common practice of dependencies between modules_
-1. Base layer calls convention layer
+1. Base layer calls domain layer
     * _Usually not recommended!_
-4. Convention layer calls base layer in another module
+4. Domain layer calls infrastructure layer in another module
     * _This sometimes can make sense, e.g. if module B just needs some low-level function of module D instead of full provisioning. 
-      However, in most cases it is recommended to call the convention layer of module D whenever possible_
+      However, in most cases it is recommended to call the domain layer of module D whenever possible_
-5. Convention layer calls base layer in another module, which only has base layer
+5. Domain layer calls infrastructure layer in another module, which only has infrastructure layer
-    * _Common practice for calling utility modules, which don't have a convention layer._
+    * _Common practice for calling utility modules, which don't have a domain layer._
 

docs/Release.md

@@ -0,0 +1,8 @@
+# How to create a release
+
+A release can be created by creating a git tag for a commit. The tag must follow this pattern: 
+v1.2 or v1.2.3
+
+I.e.: vX.X.Z where X, Y, Z are the major, minor resp. the patch level of the release. Z can be omitted.
+
+**Note:** Such kind of release tags should only be applied to commits in the master branch.