Android: Process Update

[AndyScherzinger]

Hi everyone,

@tobiasKaminsky and I had a short discussion today how we could further fine tune the development process we have and came up with the following changes.

• If a PR is considered done (reviewed, tested and labeled to release) it shall be merged
• No upfront release planing (anymore), if a considerable amount of PRs has made it to master (5+) consider doing a release
• Issues and PRs will be assigned to the next milestone right after merging (if no milestone is available, create one: (X.X.?)
• Issues and PRs are only prioritized via the labels (low, medium, high) to give a indication what is important at the moment
• As soon as a RC tag is done we freeze the master and done PRs are forbidden to be merged except for bugfixes introduced in the upcoming release's RCs

If we realize that we did quite some larger PRs as in features then a already created milestone X.X.? can be renamed to X.?.0 to make it a feature release.

Hope I didn't explain it too complicated (it should be a simpler process than we already have today).

What do you think?
@mario @przybylski

[jancborchardt]

Sounds good, loose like in other apps. One question: how long will the master be frozen?

[tobiasKaminsky]

Master will be frozen from first release candidate (RC1) till final release of the version.
Every RC will be 2 weeks in test phase, with ~300 beta testers, and if no big bug occurs, it will be the final, if not we will have to publish a new RC, again with ~2 weeks delay.

[tobiasKaminsky]

But meanwhile the master is frozen we can of course implement new features (creating new PRs), but just cannot merge them into master.

[AndyScherzinger]

Exactly.

If devs agree the two weeks can be shortened for higher RCs, eg with 1.4.1 RC4, we are probably fine with ~1 week if nothing comes up.

As for the freeze, in case a freeze blocks integrations, we still have the beta to test drive new features during that time, or open up an integration branch. The benefit is that the freeze is a natural prioritization of the hardening of the upcoming release over pushing forward new features :)

[tobiasKaminsky]

Please no integration branch.
We should keep the process as simple as possible :-)

[AndyScherzinger]

Yes, totally!
I wouldn't put integration branches in the regular process but wanted to at least mention them here as some kind of a last resort,decided on demand, in case we have a freeze but 10 very active contributors. Highly theoretical at the moment ;)

[mario]

Greetings maestros of the valley!

My suggestions (where I suggested nothing, I agree 100%):

• no upfront release planning except for major NC releases where we should aim to make a release in sync with the server release

• limit feature releases to once every two months even if we merged bunch of PRs (we can always backport stability/bugfixes and release a bugfix release) - reason for this is so we don't end up supporting bunch of "major" versions because people didn't update - and this DOES happen on Android more often than not. So month feature coding, 1 week bugfixing, 2 weeks RC1, 1 week RC2 and hopefully a release after that. So basically, branch a bugfix release off of a tag and backport fixes from master there.

• low/medium/high - while good for us, to an outsider it might be strange that his PR was assigned low priority. Maybe word it differently.

Thoughts? :)

[mario]

Thinking a bit further after developing for a bit of time

• master freeze is a silly idea
• once we're ready for a new feature release, tag (say 1.4.0) and create 1.4.x branch out of it
• use master for further development
• backport new fixes to 1.4.x branch and release 1.4.x releases from that

This is proven to work, doesn't impose artificial freeze and will allow us to develop and merge faster.

If you agree with this, I'll be more than happy so submit a PR with process update.

@AndyScherzinger @tobiasKaminsky @przybylski

[AndyScherzinger]

I had another discussion on this with @mario yesterday proposing a slight change to his proposal where I think it can help us with speed but will keep the focus on bugfix releases rather than feature releases and won't need master freezes.

• Once we start working on a new feature release we create a branch based on master, e.g. 1.5.x (which includes 1.5.0!)
• bugfixes for the actual stable (e.g. 1.4.1) always target master

This way we don't slow down bugfix releases where fixes need to be backported but rather the other way around, since the feature-release branch will have to be rebased against master to get the fixes. Ans also this way the master is chronologically fitting the actual releases.

cc: @tobiasKaminsky @przybylski @mario

[mario]

@AndyScherzinger ok, it's a bit clearer now.

While I'm not a (big) fan of the suggested approach (I dislike rebases for no good reason, but I understand the chronology reasoning), I think it's better than what we have now, so if this is a compromise, let's do it! :)

[tobiasKaminsky]

Once we start working on a new feature release we create a branch based on master, e.g. 1.5.x (which includes 1.5.0!)

With this approach we loose the opportunity to have the strings translated as early as possible (if we would merge a PR directly to master). So when will the strings be translated?

[tobiasKaminsky]

I have found (yet another oO) approach: https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/

https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/cactus-model-100.png

For me it looks better as we merge a feature directly on master (and thus it can get directly translated)
At a certain point we branch off a release branch, in which only bugfixes are made, which are backported.

Obviously we cannot develop two releases in parallel, but this is nothing I ever wanted ;-)
Another drawback is that we cannot release a e.g. 1.4.x which only contains bugfix as we (maybe) already have merged new features. But this is also something new and I (personally) do not see the benefit of a distinction between bugfix and feature releases: if a feature is ready and tested, we should get it in the next release. Same applies to bugfixes. And if we need an hotfix, we can just release a version with only one PR in it (the hotfix).
For me this approach is very very simple, but yet enough powerful.

[mario]

@tobiasKaminsky so, here are my comments assuming I've read this correctly:

• I already suggested release branches, but @AndyScherzinger mentioned he want master to be a release history - cc @AndyScherzinger
• we can't really commit directly to master, and should probably avoid especially since we need reviews - but we can use fast-forward merges instead of merge commits for sure

Thoughts on the proposals so far, and based on this final comment?

@AndyScherzinger @tobiasKaminsky

[mario]

Also, just fyi, but not of real significance:

"Another drawback is that we cannot release a e.g. 1.4.x which only contains bugfix as we (maybe) already have merged new features."

Sure we can. Branch off of the tag, release, merge back to master.

[tobiasKaminsky]

Right. Cactus model seems not to be our way.

[strugee]

Not going to comment on the proposed branching model here since I don't know enough about the motivations, but a quick note on milestone names: don't rename milestones every time you release. When I switched pump-io/pump.io to a time-based release schedule, I started off thinking I'd do it that way too, but doing it that way usually means that you always end up going and modifying a bunch of issues' milestones when you do releases. It's easier to just create a "Future" milestone and put accepted stuff in that. You can create a "Near future" milestone too, to track stuff that's really close to making it in.

[jancborchardt]

@strugee we do that in the server and it's ok. It makes it clear what is planned for which version, roughly. If something falls off the current version, it can be postponed or even mass-reassigned.

[strugee]

@jancborchardt yeah, I personally found the mass-reassignment to be a PITA, but hey. Whatever works :)

I think I misread the proposal (and the way the server does things), though - in the pump.io project we release periodically with whatever went in during that time, but what's being proposed here is almost the opposite - just doing a release whenever enough features have made it in. So I guess my comment doesn't make a whole lot of sense after all 🙄

Cheers!

[tobiasKaminsky]

@mario as discussed on IRC you wanted to create a diagram for the new process idea

[mario]

So ... can we for now agree that once RC1 is out, we can start a 1.5 branch which will be merged to master as soon as real 1.4.2 is out? That way we can merge all reviewed branches to 1.5 and later on into the master.

[AndyScherzinger]

To not loose time I'd say, let's do it the way you proposed, which will also mean that the PRs need to be opened once more since the target branch of a PR can't be changed and they all target master at the moment.

[strugee]

@AndyScherzinger yes you can; they changed it relatively recently. Just hit edit in the upper-left and the base branch will turn into a dropdown.

[AndyScherzinger]

Didn't know that! That is awesome news, thanks for the hint @strugee ! :)

[tobiasKaminsky]

As we have a new release idea and also updated contributing.md I am closing this.