If you want to contribute just take some issue here on github. If you want to ge deeper into project planning or get social get access to Slack
Techstack: Kotlin, XML layouts, Jetpack (Navigation, DataStore, Room, Material.io), Kotlin coroutines, Mockito MVVM, Repo
- feature based packaging
- always use 'rebase'
- 'main' - development branch
- 'release' - Do not use merge. Once the main branch is ready for internal testing, use 'rebase main'. It will push by CI to Gplay for internal testing.
- use 'feat/featureName','dev/developerName','bugfix/fixDesc' ...
We communicate thru slack, google meet, github issues and rarely trello (Mostly in czech language but it won't be problem to switch to english. It is used mainly for ideas kickoff, UX, QA) Trello Slack search for channels 'movapp'
see github actions pane Fastlane - push to 'release' branch goes to Gplay internal testing, when tested by QA, they are pushed to production.
We use x.y.z versioning, where increasing x is reserved for major changes, y should be increased for public release, and z for internal testing. Always add a tag with version increasing.
- in
app/build.gradle
increaseversionName
- merge branch
main
torelease
(this executes release to internal testing on Gplay) - add git tag with version ie.
1.2.3
fromversionName
, tag message should beVersion 1.2.3
(just for info, no automation relates to it) - manage testing requirements thru Movapp-Gdrive/Testovani
- contact QA thru slack to start testing
- once the version is ready for public release, log into google console and move the version from internal testing to production
members having release signing keys and access to Gplay console: zoul, vchlum, OndrejMalek