Changes in 104aeec: Renamed master branch to "main" in Wiki building-and-deploying article

				wiki/info/landscape/building-and-deploying.md
			
          @@ -42,7 +42,7 @@ $ ./refreshInstance.sh install-release build-201712210442

           $ ./stop; ./start

           </pre>

          -Instead of building a release yourself you can let the build server to the job. There is a job that looks out for a git tag named `release`. If a new revision is found then an automatic release build is being executed. The result of that is persisted to http://releases.sapsailing.com/. You can create that tag as follows. Make sure that you're on the current master branch before executing the following commands.

          +Instead of building a release yourself you can let the build server to the job. There is a job that looks out for a git tag named `release`. If a new revision is found then an automatic release build is being executed. The result of that is persisted to http://releases.sapsailing.com/. You can create that tag as follows. Make sure that you're on the current main branch before executing the following commands.

           <pre>

           $ git tag -f release

          @@ -98,7 +98,7 @@ Since we want to build and release two apps out of one Git repo and ideally with

           - ``release-buoy-pinger-app`` to release the SAP Sailing Buoy Pinger app with MoMa assembly ID 188

           - ``release-race-manager-app`` to release the SAP Sailing Race Manager app with MoMa assembly ID 189

          -Both these branches derive from the branch ``hyperspace`` which is more like a proxy branch as its original changes with the pipeline / fastlane definition and a few changes to the top-level README and .gitignore files have now been merged fully into the master branch where they have no averse effects. However, pushing onto the ``hyperspace`` branch will trigger the Azure DevOps pipeline for a full build including "tests" and "scans." However, since we don't have any app-specific UI tests and instead focus on unit tests for the logic shared also with the back-end and GWT UI ("common" and "shared" bundle projects), we "simulate" successful tests to satisfy the build pipeline's requirement for tests to be present. See files ``dummy/TEST-dummy.xml`` and ``dummy/jacoco/jacocoTestReport.xml``. This lets the "quality" stage of the Azure Pipeline pass without complaints. The two app-specific branches each make four important adjustments compared to the ``hyperspace``/``master`` branch:

          +Both these branches derive from the branch ``hyperspace`` which is more like a proxy branch as its original changes with the pipeline / fastlane definition and a few changes to the top-level README and .gitignore files have now been merged fully into the main branch where they have no averse effects. However, pushing onto the ``hyperspace`` branch will trigger the Azure DevOps pipeline for a full build including "tests" and "scans." However, since we don't have any app-specific UI tests and instead focus on unit tests for the logic shared also with the back-end and GWT UI ("common" and "shared" bundle projects), we "simulate" successful tests to satisfy the build pipeline's requirement for tests to be present. See files ``dummy/TEST-dummy.xml`` and ``dummy/jacoco/jacocoTestReport.xml``. This lets the "quality" stage of the Azure Pipeline pass without complaints. The two app-specific branches each make four important adjustments compared to the ``hyperspace``/``master`` branch:

           - The ``isRelease`` property is set to ``true`` for both app release branches to force the signing / releasing process

           - The ``buildOutputPath`` is set to ``mobile/{app-directory}`` for the respective app to limit the number of files staged (artifacts staged are the unsigned .apk file, the files2sign.json and the zipped archive of all sources that went into the app)

...	...	@@ -42,7 +42,7 @@ $ ./refreshInstance.sh install-release build-201712210442
42	42	$ ./stop; ./start
43	43	</pre>
44	44
45		-Instead of building a release yourself you can let the build server to the job. There is a job that looks out for a git tag named `release`. If a new revision is found then an automatic release build is being executed. The result of that is persisted to http://releases.sapsailing.com/. You can create that tag as follows. Make sure that you're on the current master branch before executing the following commands.
	45	+Instead of building a release yourself you can let the build server to the job. There is a job that looks out for a git tag named `release`. If a new revision is found then an automatic release build is being executed. The result of that is persisted to http://releases.sapsailing.com/. You can create that tag as follows. Make sure that you're on the current main branch before executing the following commands.
46	46
47	47	<pre>
48	48	$ git tag -f release
...	...	@@ -98,7 +98,7 @@ Since we want to build and release two apps out of one Git repo and ideally with
98	98	- ``release-buoy-pinger-app`` to release the SAP Sailing Buoy Pinger app with MoMa assembly ID 188
99	99	- ``release-race-manager-app`` to release the SAP Sailing Race Manager app with MoMa assembly ID 189
100	100
101		-Both these branches derive from the branch ``hyperspace`` which is more like a proxy branch as its original changes with the pipeline / fastlane definition and a few changes to the top-level README and .gitignore files have now been merged fully into the master branch where they have no averse effects. However, pushing onto the ``hyperspace`` branch will trigger the Azure DevOps pipeline for a full build including "tests" and "scans." However, since we don't have any app-specific UI tests and instead focus on unit tests for the logic shared also with the back-end and GWT UI ("common" and "shared" bundle projects), we "simulate" successful tests to satisfy the build pipeline's requirement for tests to be present. See files ``dummy/TEST-dummy.xml`` and ``dummy/jacoco/jacocoTestReport.xml``. This lets the "quality" stage of the Azure Pipeline pass without complaints. The two app-specific branches each make four important adjustments compared to the ``hyperspace``/``master`` branch:
	101	+Both these branches derive from the branch ``hyperspace`` which is more like a proxy branch as its original changes with the pipeline / fastlane definition and a few changes to the top-level README and .gitignore files have now been merged fully into the main branch where they have no averse effects. However, pushing onto the ``hyperspace`` branch will trigger the Azure DevOps pipeline for a full build including "tests" and "scans." However, since we don't have any app-specific UI tests and instead focus on unit tests for the logic shared also with the back-end and GWT UI ("common" and "shared" bundle projects), we "simulate" successful tests to satisfy the build pipeline's requirement for tests to be present. See files ``dummy/TEST-dummy.xml`` and ``dummy/jacoco/jacocoTestReport.xml``. This lets the "quality" stage of the Azure Pipeline pass without complaints. The two app-specific branches each make four important adjustments compared to the ``hyperspace``/``master`` branch:
102	102
103	103	- The ``isRelease`` property is set to ``true`` for both app release branches to force the signing / releasing process
104	104	- The ``buildOutputPath`` is set to ``mobile/{app-directory}`` for the respective app to limit the number of files staged (artifacts staged are the unsigned .apk file, the files2sign.json and the zipped archive of all sources that went into the app)