Apps-android-commons: Changing our release and hotfix system

[misaochan]

Currently, all releases are done from master, and all hotfixes to release issues are also submitted to master. Brief history of the problems that we are encountering with our current release system:

• We had a major issue with Dagger crashes in 2.6.5, which was solved by #1062
• #1062 was released via 2.6.6
• 2.6.6 fixed the Dagger crash from 2.6.5, but also included other changes that caused a different type of crash, with an even higher crash rate
• We wanted to roll back to 2.6.5 while cherry-picking the Dagger fixes
• This turned out to be extremely difficult because the Dagger fixes built on other code changes that were submitted to master between 2.6.5 and 2.6.6.

In the future, I'm thinking that we might want to change how we do hotfix releases. My proposed new system:

• Every major release (e.g. 2.6), I will pull from master and create a new branch (e.g. 2.6.x-release)
• Hotfixes to the major release must be done in the 2.6.x-release branch, not in master
• Hotfix releases (e.g. 2.6.1) will be pulled from the 2.6.x-release branch. New changes/enhancements to master will not be included in the hotfix release
• Release branches will be merged into master periodically (so master is up to date with hotfixes made to release branches)
• Hotfixes can be released to production after being tested in beta for a few days. Major releases on the other hand should be tested in beta for a much longer time (e.g. 2 weeks?)

I believe that this will allow us to make hotfixes more easily and independently of master, and reduce the headaches that we are facing currently. Given that major releases are expected to be the least stable, they should also be tested the most vigorously.

[psh]

I like what you've outlined. 👍

In this scheme, master is potentially unstable and represents the next planned version, and there are clearly defined, stable branches representing each release.

If you're outline branching strategy as well as release strategy, it is worth mentioning the role that _feature branches_ play in terms of isolating highly experimental features, to keep master as stable as possible?

[misaochan]

Thanks @psh . :)

Re: feature branches, indeed we have tried using them a bit, but currently their use is restricted to large features that more than one person is collaborating on (e.g. direct nearby). Do you think we should be using them more than we currently are?

[psh]

I think you've outlined a nice lightweight process with minimal branching, it all looks good to me.

[nicolas-raoul]

The workflow you described is great, actually I have used it successfully in other projects.

Feature branches are great too, though they should get merged into master as soon as possible (as soon as the feature is ready) to avoid late bad surprises. It is more important than always having a stable master.

[misaochan]

Thanks guys! I'll add this to the wiki then. :)

@maskaravivek and @neslihanturan , if you guys are good with this, we can start implementing this system in the next release.

[domdomegg]

Workflow now in use and documented on wiki.