[RFC] - 101: Workflow

[frapontillo]

This issue will be updated with workflow guidelines, that will then be finalized and added to a md file.

Workflow (RFC proposal)

Gitflow

The workflow must follow the gitflow pattern:

1. Use feature/* for new features or delayable bug fixes
2. Use hotfix/* for immediate bug fixes that must be propagated to stable, beta and develop channels
3. Use develop for project changes, minor changes, etc.

Version numbers

1. The version should follow the MAJOR.MINOR.PATCH-BRANCH.BUILD pattern. The BRANCH.BUILD part will be useful when releasing CI builds on beta/alpha channels.

   a. If we are working on the, say, 3.1.2 codebase, every minor update that needs to be pushed to beta and alpha channels must be a simple BUILD bump
   b. When a new version is started, all subsequent changes must be released under a new MAJOR.MINOR.PATCH (i.e., the BUILD is reset to 0).
   c. This way, the app will always be incremental by 1 unit number.

2. The version number must be bumped right after releasing the previous apk, so the system may be able to simply touch the BRANCH.BUILD part.

Issues and features

When working on issues and new features:

1. For soon-to-be-released fixes and features, we can close the issue and merge the related branch into develop.
2. For to-be-determined features, we can close the issue in the last commit of the branch but we cannot merge the branch back into develop.
3. The hotfix or feature branch must be in the ISSUE-SHORT_DESC format, so it can be visually connected to an issue.
4. After a branch is merged into develop and the related changes have been put into a release, the hotfix or feature branch must be deleted.

Continuous Integration

We should promptly set up a CI system that, on every commit on develop, will take care of:

1. Test the project.
2. Bump the BRANCH.BUILD in the unstable.### format.
3. Build an develop release.
4. Upload the apk somewhere.

[rock3r]

My comments:

1. In the CI section we should add:

   a. The CI system performs static analysis on the code (eg. Sonar, Lint) and halts in case of serious issues
   b. The CI system pushes the app's new strings (only the sources) to Crowdin
   c. The CI system must automatically update the app's Manifest, while preparing a release (see Git-Flow release cycle)
   d. There is some mechanism that pulls updated strings before proceeding to build the app, when bumping the version (the major, minor or patch fields only, of course)

2. I see a big issue here: the Play Store allows you to promote a well-tested build from alpha and beta channels to "better" channels (eg. alpha -> beta, beta -> prod). If we tag the builds using the MAJOR.MINOR.PATCH-BRANCH.BUILD pattern, the BRANCH.BUILD part will cause issues because it will contain unstable, making the release unsuitable to be promoted on the Play Store.

3. It is allowed to work directly on develop to do simple, one-liner fixes of issues. No point in creating a feature branch when you only have to fix a typo. The versioning stuff stays the same, thou.

4. Features must be rebased on develop after each tagged release, if they are still not merged into develop, to keep the history clean

5. We're missing the criteria to distinguish major and minor versions. Patches are of course only going to have bug fixes (code, resources, etc), but can we have minor versions with new features (eg. a better caching mechanism)? And if we can, what feature(s) is/are worth of a major version bump?