| commit | c409e63ce5dfd58b02386ea88b56995f08465075 | [log] [tgz] |
|---|---|---|
| author | Borjan Tchakaloff <borjan@fairphone.com> | Fri Dec 30 16:07:17 2016 +0100 |
| committer | Borjan Tchakaloff <borjan@fairphone.com> | Fri Dec 30 16:07:17 2016 +0100 |
| tree | ea4c06f690134c70cb9c8cf4323a4f999949c79d | |
| parent | 83df86d2f45e45ba769a1e3c3e664ec887e51b49 [diff] |
Bump version to 2.1.1 (20101) Change-Id: I64ca1b0d3456465b9ac6ea57128127d8a4afbfaa
An Android app that allows end-users to test their Fairphone 2 features.
The up-to-date development branch. It should always be build-able.
Solo commits (not part of a feature branch nor a bugfix branch) should be avoided. Version bumping is the exception and happens directly on the branch.
Accepts completed feature branches -that will lead to a new release- and cherry-picks of bugfix branches -to be integrated forth-.
A release branch coming off master.
Each tagged release release-X.Y.Z can be built and will be equivalent to what what released as this version. Fingerprint will vary based on the builder, features and version will not.
Only accepts bugfix branches that then bumps the revision number.
A bugfix branch coming off a release-X.Y branch.
Work in progress until merged back to the release branch.
A feature branch coming off master.
Work in progress until merged back to master (will be integrated in a future release).
New features are implemented in feature branches -and therefore must have an issue ID- that are merged back to master when complete.
Note: A feature branch must not be merged into a release branch. The release branch scope is restricted to bugfixing.
When master is ready to be released, a new release branch is created with either the major or the minor version bumped (see the rules in the next section).
Bumping the version must happen in master before branching out. That way, the master branch can be built and installed on previous releases and is still considered part of the next (now on-going) release.
FIXME: The version of master should be clearly different from a release. Having a higher version allows us to -always- be able to install master on top.
Each release is tagged following release-<major>.<minor>.<revision> and belongs to a release-<major>.<minor> branch.
Because the bugfix branches fix_CHK-N are related to specific releases, they are branched off and merged back to specific release branches.
Once merged back in the release-X.Y branch, the minor version Z is then bumped with a new commit and a new tag release-X.Y.Z is created.
If the fix can be applied to master and other release branches, the bugfix branch fix_CHK-N is forth- and back-ported as required. Once again with release branches, the minor version needs to be bumped. No version is bumped on master.
The app version (a.k.a Version Code) is based on the following scheme:
The rules are as follow:
The readable app version (a.k.a Version Name) is based on the app version with the following schemes: