Gitiles
Code Review Sign In
gerrit-public.fairphone.software / fp2-dev / vendor / fairphone / packages / apps / ProximitySensor / 9525186a60293c14c3156a2e5e49908ed544cd2f
commit9525186a60293c14c3156a2e5e49908ed544cd2f[log] [tgz]
authorMaarten Derks <maarten@fairphone.com>Wed Nov 16 11:57:41 2016 +0100
committerMaarten Derks <maarten@fairphone.com>Wed Nov 16 11:57:41 2016 +0100
tree107591dbeecf0f82dbd5a16ac9b9fb4306e34289
parent79891caceb7ffdc487b67fa5074d7151fc49afa9 [diff]
Remove old launcher icon
5 files changed
tree: 107591dbeecf0f82dbd5a16ac9b9fb4306e34289
  1. app/
  2. gradle/
  3. .gitignore
  4. Android.mk
  5. build.gradle
  6. gradle.properties
  7. gradlew
  8. gradlew.bat
  9. README.md
  10. settings.gradle
README.md

Description

The calibration algorithm is documented in the CalibrationActivity file.

Versioning

The app version (a.k.a Version Code) is based on the following scheme:

  • Major version number
  • Minor version number
  • Release status number (snapshot/release candidate/public release)

The rules are as follow:

  • The major version uses two digits
  • The minor version uses two digits
  • The release status uses two digits
  • The major version should be bumped when introducing new features
  • The minor version should be bumped whenever there is a (simple/hot) fix
  • The release status must be 0 while developing (snapshot)
  • The release status must be in [1;98] while testing releases (release candidate)
  • The release status must be 99 for a public release

The readable app version (a.k.a Version Name) is based on the app version with the following schemes:

  • Snapshots are named after <major version>.<minor version>-SNAPSHOT
  • Release candidates are named after <major version>.<minor version>-RC<release status>
  • Public releases are named after <major version>.<minor version>

TODO: implement an automatic translation from app version to readable app version

TODO: implement an automatic version bumping task when pushing/merging/integrating features/fixes