doc improvement

README.md

@@ -1,16 +1,78 @@
 # init.sh
-**init.sh** is an automated configurator for system administrator. It's fully written using Bash scripting and aims to be platform independent. Nevertheless it's requirements turns it naturally to Linux systems. It have long been tested using Debian GNU/Linux, Devuan and different flavor of Ubuntu.
+**init.sh** is an automated configurator for system administrator. It's fully
+written using Bash scripting and aims to be platform independent. Nevertheless
+it's requirements turns it naturally to Linux systems. It have long been tested
+using Debian GNU/Linux, Devuan and different flavor of Ubuntu.
 
 ## Getting started
-You should consider reading the Beginners guide. If you need to create additional modules to meet your needs, consider reading the Developers guide.
+You should consider reading the Beginners guide. If you need to create
+additional modules to meet your needs, consider reading the Developers guide.
 
-Please also consider that your needs might meet the needs of someone else, thus it would be a good idea to submit your module to init.sh source base.
+Please also consider that your needs might meet the needs of someone else, thus
+it would be a good idea to submit your module to init.sh source base.
 
 ## Design
 **init.sh** relies on three different elements to work:
 
-- the init.sh script, which provide a simple framework and libraries to do simple taks and embed system dependent functions to provide system independent function calls.
-- modules that actually do the job on a system independant way through the use of the framework and consisting on very small and simple task.
-- multilevel configuration files, being just Bash variables declaration.
+- the init.sh script, which provide a simple framework and libraries to do
+simple taks and embed system dependent functions to provide system independent
+function calls.
+- modules that actually do the job on a system independant way through the use
+of the framework and consisting on very small and simple task.
+- multilevel configuration files, being simply Bash variables declaration.
+
+Additionally some module might be ran regularly so it could be integrated in a
+cron-like service.
+
+### Basic module structure
+
+Please note that modules are not supposed to contain any specific code for a
+platform or a distribution even if nothing block you doing so. It is highly
+recommended to use configurations files to introduice any platform dependent
+code.
+
+In the following exemple @template@ have to be replaced par le nom de votre
+module qui doit être nomé @template@.sh. Vous pouvez automatiquement créer votre
+nouveau module avec la commande suivante :
+
+```shell
+sed -e "s/@template@/nom_module/g" -e "/^# .*/d" -e "s/^##/# /" template > \
+    nom_module.sh 
+```
+
+Versionning modules is up to you but the recommended behavior follows somme
+standard rules. Considering a numbering as x.y.z:
+
+- x might be incremented in case of major change, rewriting or deferent approach
+on the way to have the job done
+- y might be incremented in case simple finctionnality addition or basic
+improvements
+- z might be incremented only when correcting problems and/or bugs (+n fix => +n
+increment)
+
+Unless only configuration files have been changed, any change in the code
+implies any increment of a version number in the code **and** a git commit.
+
+```shell
+# Description @template@ module
+
+# Modiule version
+export VER_@template@="0.0.1"
+
+# Module main code
+@template@()
+{
+    # Code
+}
+
+# Pre-run checks code
+precheck_@template@()
+{
+    # Code
+}
+
+# Any public fonction have to be exported
+export -f @template@
+export -f precheck_@template@
+```
 
-Additionally some module might be ran regularly so it could be integrated to a cron-like service.