a42cc871904aa57361a71c7f174bc6840819d09f
wiki/info/landscape/building-and-deploying.md
| ... | ... | @@ -115,7 +115,7 @@ We currently release the Android apps off a branch called ``android-xmake-releas |
| 115 | 115 | |
| 116 | 116 | The Android release branch holds the changes required to run a successful Android build in xMake. This cannot be overestimated, and credits go to Steffen Schaefer for pulling this off! Check out the specificities for the Android build in the top-level ``pom.xml`` file and you see why this was such a great achievement. |
| 117 | 117 | |
| 118 | -We have various branches on which Android mobile app features are being developed. Ultimately, they should be merged into the ``master`` branch from where they get merged into the Android release branch. A so-called "Customer release" build can be triggered for the Android release branch on a [central Jenkins instance](https://xmake-ldi.wdf.sap.corp:8443/view/SAPSail/job/sapsailingcapture-Release/). However, it is important to know that the xMake build profile will make sure that the version specified in the ``pom.xml`` descriptors matches in its major and minor version with a ``rel-x.y`` branch name in the central git repository at ``git.wdf.sap.corp``. For example, if the ``pom.xml`` files specify a ``1.4.0`` version, the commit to be built needs to be contained in a branch called ``rel-1.4``. |
|
| 118 | +We have various branches on which Android mobile app features are being developed. Ultimately, they should be merged into the ``master`` branch from where they get merged into the Android release branch. A so-called "Customer release" build can be triggered for the Android release branch on a [central Jenkins instance](https://xmake-mobile-dev.wdf.sap.corp/job/sapsailingprogram/job/sapsailingcapture.android-OD-dockerrun/). However, it is important to know that the xMake build profile will make sure that the version specified in the ``pom.xml`` descriptors matches in its major and minor version with a ``rel-x.y`` branch name in the central git repository at ``git.wdf.sap.corp``. For example, if the ``pom.xml`` files specify a ``1.4.0`` version, the commit to be built needs to be contained in a branch called ``rel-1.4``. |
|
| 119 | 119 | |
| 120 | 120 | Also note that once released to Nexus, the next release build will have to use at least an incremented micro version, such as 1.4.1. In order to change all versions in all `MANIFEST.MF` and `pom.xml` files consistently, the Tycho `set-version` plugin can be used. For this, the `<parent>` definition in the top-level `pom.xml` file needs to be commented out, which points to `com.sap.ldi/ldi-parent/8.0.0` or else you will get error messages that this component cannot be found (it is only found when the build is run on a central Jenkins instance that sees the Nexus repository at the right place). Then, you would have to issue the following command, setting the version number as required: |
| 121 | 121 |