| commit | bbf4ff17c4d5d1f2552bce16c321610440742dd6 | [log] [tgz] |
|---|---|---|
| author | Maarten Derks <maarten@fairphone.com> | Mon Oct 04 09:14:59 2021 +0200 |
| committer | Maarten Derks <maarten@fairphone.com> | Mon Oct 04 09:14:59 2021 +0200 |
| tree | 09c8e6ecd2780e401bf2df9ec199dae1c1a7afbc | |
| parent | f88a34a42a6ee47fec78cdc886e248cdfcfd5c3d [diff] |
Bump version to 2.2.2 (20202) Change-Id: I23379ed6af9d34913113c8d1afe1d7b1ca7ceb76
An Android app that allows end users to test the features of their Fairphone 2.
If you are looking for build artifacts, please have a look at the prebuilts branch.
The app version (a.k.a. version code) is an integer based on the following scheme:
<major version><minor version><revision>The rules are as follows:
The visible app version (a.k.a. version name) is a string based on the version code, with the following scheme:
<major version>.<minor version>.<revision>Note: The version code features leading zeroes between numbers so that it matches the full pattern, the version name does not. A release with a version code of “10203” is named “1.2.3”.
The master branch is the up-to-date development branch. It should always be buildable.
Only completed feature branches that will lead to a new (major or minor) release, as well as cherry-picks of hotfixes to be integrated forward, can be merged into the master branch.
New features are implemented in dedicated branches that are coming from and merged back into master when complete.
They are named after the issue ID they are solving. No feature should be implemented without a logged issue backing it.
Note: A feature branch must not be merged into a release branch. The release branch scope is restricted to bug fixing (hotfix).
When master is ready to be released, a new commit is created with either the major or the minor version increased (cf. versioning scheme).
Increasing the version must happen in master. That commit represents the new release.
Each release is tagged following the release-<major>.<minor>.0 scheme and a new release branch release-X.Y is created from there. The release branch scope is strictly limited to hotfixing.
New release branches release-X.Y begin at the release commit release-X.Y.0 from master.
Note: The revision number cannot be bumped in master as it is only applicable to hotfixes, and those do not happen in master but in release branches.
FIXME: The release tags should be signed off by a Fairphone developer.
Bug fixing is relative to an identified release, it happens on a specific release branch. We only consider hotfixes, design flaws and higher level considerations should be handled as new features. A hotfix is usually a single commit.
If the hotfix can be applied to master or other release branches, the hotfix is cherry-picked whenever possible to keep the relationship to the original commit. Note that the version number is not bumped on master when integrating a fix.
The current release revision Z is eventually bumped with a new commit, and a new release (release-X.Y.Z+1) is created.
Releasing a new version happens at the code level. We now use a prebuilt approach to have a shared release between the different operating system flavours running on the Fairphone 2. This approach also allows for OTA updates through app markets.
The prebuilts branch versions the official build artifacts from a named release (in the form of prebuilts-X.Y.Z), signed with the widely known Fairphone key. They match a source code release (release-X.Y.Z) (from the master branch).
Updates to prebuilts take the form of prebuilts-X.Y.Z-MR_N_ where N is a natural number denoting the update number. Such updates can only happen if the change is limited to the build system. If a source code change is needed, its version cannot be maintained and thus a new release is required.
Note: There is only one release supported at a given time, hence using a single branch to version the prebuilts artifacts is not an issue.
Checkup can be built using Android Studio or directly with Gradle.
In order to build in Android Studio, import the root of the Git repository as a new project and use the features of the IDE to edit, build, run, and debug Checkup.
To build from commandline you will need the Android SDK and Gradle. Follow the instructions in Android documentation.
By default both debug and release build variants are signed using default keys included in the Android SDK. To sign the app for release, you need
The release key can be put in a keystore using a script in vendor/fairphone/tools/.
Point the build system to the keystore using a configuration file which includes the path to the keystore, the alias of the key, and passwords for keystore and key. The file keystore.properties needs to be at the root of the Git repository and contain information like:
storePassword=<pwd-of-keystore> keyPassword=<pwd-of-key-in-keystore> keyAlias=CheckupReleaseKey storeFile=../relative/path/to/checkup.keystore
You can verify that Gradle can find and open the key by checking the output of gradlew signingReport. The sections for release and releaseUnitTest variants should look similar to:
Variant: release Config: release Store: /absolute/path/to/checkup.keystore Alias: CheckupReleaseKey MD5: 7D:F2:FC:AA:FD:75:F3:83:5C:ED:AE:63:B7:F2:AD:AB SHA1: 30:63:51:FB:98:33:47:1A:26:00:2D:58:C7:F1:1D:76:DE:F0:34:8E Valid until: Monday, November 24, 2042
If configuration is correct, gradlew assembleRelease can be used to create the signed app at ./app/build/outputs/apk/release/app-release.apk.