Update README

README.md

@@ -3,6 +3,7 @@ This repository holds the site configurations for the following Freifunk MWU (Ma
 
 * [Freifunk Mainz](http://www.freifunk-mainz.de)
 * [Freifunk Wiesbaden](http://wiesbaden.freifunk.net)
+* [Freifunk Bingen](https://www.freifunk-bingen.de)
 * [Freifunk Rheingau-Taunus](https://www.freifunk-rtk.de)
 
 ## Repository structure
@@ -16,31 +17,29 @@ To ensure that the submodule is initialized correctly, call `git submodule updat
 To update gluon to the latest `origin/master` use `git submodule update --remote`.
 
 ## Version schema
-For the versioning of our _stable_ and _testing_ releases we use the Gluon version and append the string `mwu` followed by a counter. The counter starts at 1 and will be increased if we do maintenance releases with the same gluon version as the current release. For example the first release based on gluon v2018.1.2 would be `2018.1.2+mwu1`.
+For the versioning of our _stable_ and _testing_ releases we use the Gluon version and append the string `mwu` followed by a counter. The counter starts at 1 and will be increased if we do maintenance releases with the same gluon version as the current release. For example the first release based on gluon v2018.2 would be `2018.2+mwu1`.
 
-For _experimental_ builds this is slightly different. They also start with the Gluon version (as we don't have a Git tag we use a predefined prefix) followed by `mwu`. But the suffix doesn't include the regular counter instead we add a second suffix that reflects the build date followed by an incremental counter in case we build several times a day. For example the first experimental build of 30.11.2018 would be called `2018.2+mwu~exp2018113001`.
+For _experimental_ builds this is slightly different. They also start with the Gluon version (as we don't have a Git tag we use a predefined prefix) followed by `mwu`. But the suffix doesn't include the regular counter instead we add a second suffix that reflects the build date followed by an incremental counter in case we build several times a day. For example the first experimental build of 29.12.2018 would be called `2019.1+mwu~exp2018122901`.
 
 ## Build the firmware
 The firmware can be build using the `build.sh` script contained in the repository.
 
-To do a full build with the lastest `master` use the following commands:
+To do a full build for `2018.2+mwu1` use the following commands:
 
 ```
 # clone repository and checkout at given tag
-git clone --recursive https://github.com/freifunk-mwu/sites-ffmwu.git
+git clone --recursive --branch 2018.2+mwu1 https://github.com/freifunk-mwu/sites-ffmwu.git
 
 # change to newly created directory
 cd sites-ffmwu
 
-# initialize submodule and update to latest upstream
-git submodule update --init --remote
+# initialize submodule
+git submodule update --init
 
 # start the build
-DATE=$(date +%Y%m%d)
-
-./build.sh -r 2018.2+mwu~exp${DATE}01 -c update
-./build.sh -r 2018.2+mwu~exp${DATE}01 -c clean
-./build.sh -r 2018.2+mwu~exp${DATE}01 -c build
+./build.sh -r 2018.2+mwu1 -b stable -c update
+./build.sh -r 2018.2+mwu1 -b stable -c clean
+./build.sh -r 2018.2+mwu1 -b stable -c build
 ```
 
 ## Sign and deploy the firmware
@@ -49,13 +48,13 @@ DATE=$(date +%Y%m%d)
 To create and sign the _testing_ manifest for the new images use the following command:
 
 ```
-./build.sh -c sign -r 2018.2+mwu~exp${DATE}01 -b experimental
+./build.sh -r 2018.2+mwu1 -b testing -c sign
 ```
 
 To copy the images and packages to the firmware directory, you can use the following command:
 
 ```
-./build.sh -c deploy -r 2018.2+mwu~exp${DATE}01 -b experimental
+./build.sh -r 2018.2+mwu1 -b testing -c deploy
 ```
 
 ## Automated builds
@@ -64,5 +63,5 @@ To copy the images and packages to the firmware directory, you can use the follo
 For example to do a full build _(update, build, sign, deploy)_ use the following commands:
 
 ```
-./autobuild.sh -b experimental -u -- -a
+./autobuild.sh -b testing
 ```