Development Guide discussion

[AndyScherzinger]

Hi everybody,

I just created a wiki page for a short development guide which should help new contributors to understand how develop and release new versions of the app.

https://github.com/nextcloud/android/wiki/Development-Guide

It is just a draft. I thought it is easier if we have some stuff written down to kick off the discussion. For now I focused on versioning and the code review process.

Feel free to challenge anything I have written down ;)

cc @jancborchardt @LukasReschke @tobiasKaminsky @przybylski

[jancborchardt]

Just a detail thing, I would prefer if we don’t use the Github wiki at all and have all the necessary files in the repository. Then when you clone it you have everything offline etc, and people don’t need to know that we use the wiki (cause we don’t use it otherwise).

[AndyScherzinger]

Hmm, that seems wrong to me 😉 I already highly dislike the fact that the user documentation is linked with the code repo since general documentation and code shouldn't be mixed imho. So, yes it doesn't have to be the GH wiki but I would not like it to be within the code repo either.

Edit, since we don't have much documentation dev wise (yet) we can put it into the .md file if you like. But still for every change you will need a PR and two thumbs up to even merge...

[AndyScherzinger]

The reason I dislike it is the fact that I WILL HAVE TO checkout/clone the documentation with every branch again and again and again and obviously don't care about documentation at all since this is nothing that changes between all the branches...

[tobiasKaminsky]

As this guide will change only in the beginning I am fine with a file.
But then we should discuss it here.

Some open questions I have:

• how often do we release a stable version? Fixed time slot? After x PRs merged?
• how are PRs chosen?

This should be added to make clear that every idea should be discussed prior to implementing it.

Developing roadmap:

• create issue with feature request, discuss, must be approved
• create mockup if necessary
• develop code
• create PR

[AndyScherzinger]

Sounds good to me, so let's finish up an initial version in the wiki and then put it in the Repo

[tobiasKaminsky]

Next question: who should merge? Anyone or the pr opener as he/she can verify it a last time?

[AndyScherzinger]

Good point, with two thumbs up we should be fine with anybody merging.

[tobiasKaminsky]

Next question: which labels? Same as ownCloud?
How do we distinguish proposed issues and "verified" issues?

[AndyScherzinger]

I would suggest just having a label for approved issues: "approved"

[AndyScherzinger]

how often do we release a stable version? Fixed time slot? After x PRs merged?

I would say we keep it flexible for now and decide on a case-by-case / release-by-release basis. Right now I consider, you, @tobiasKaminsky and myself being the core developers. So it is probably the three of us that usually merge stuff to master and create tags/releases for the different channels. I would for now keep it flexible since doing releases depends on our availability which might be floating.
In case we agree we do have enough new features worth and stable to be released we do one. Like with oC I would say we create a release issue with a task list and go for it. During that time we should have a feature freeze, so no new PR will be merged to master.

how are PRs chosen?

The easy answer is: When they are ready ;)
To me ready means reviewed, tested and in some cases already out in the wild via one of our beta channels. PRs should only exists and be reviewed/approved if the correspond to an approved issue so there is no argument not putting them into a release.
Only thing I can think of not putting a PR on master is if it implements a future server side feature which hasn't been released yet.

My Question + opinion
master, stable beta and beta?

• stable: as described, PRs that have been tested and reviewed can go to master. After the last stable beta published PR is out in the wild for ~2 weeks and no errors get reported (by users or in the developer console) the master branch is release ready. So when we decide to go for a new release we freeze the master feature wise
• stable beta: whenever a PR is reviewed/approved we put it on master and do a stable beta release
• beta: anything that has a certain maturity as in a PR that can be used already but might lack some on top features or polishing

[AndyScherzinger]

@tobiasKaminsky @schiessle proposed "1 to develop" as one of the general set of labels. This one could also serve as an "approved" label. What do you think?

[tobiasKaminsky]

"approved" should be an independent label to not confuse us ;)
PR:
1 in progress
2 ready to CR
3 ready to test
4 ready to release

Issue:
nothing
approved
PR exists (and then the PR # should be shown in first post)

[AndyScherzinger]

What do you think about the guidelines on when changes should go into each release channel and the steps to prepare for stable releases?

[tobiasKaminsky]

I do not fully understand the difference between "stable beta" and "beta". In beta every PR that is "ready to test" will be included by me.
And I thought the same is for "stable beta", but with the public beta test by google play store?

[bes1002t]

we have a documentation repo I thought, why do we not place the android documentation there as well?

Maybe we should use "alpha" and "beta" instead of "beta" and "stable beta"