Android: 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 :wink: 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"

[tobiasKaminsky]

alpha is more unstable than beta, at least for me.
But I understand that "stable beta" and "beta" have the same code quality...?

[AndyScherzinger]

Not imho. The stable beta is stuff we put on master but haven't released yet. That is what we then public in Google Play store as beta, if that survives for around two weeks without incidents we can release it as stable. Things we put on the master would imho be tested thoroughly already while things we put in the beta in F Droid wouldn't necessarily be.
The beta and stable in the Play store are the same app where betas only get distributed to people who joined the beta and will automatically be updated with the next upcoming stable. It is no app installed in parallel!

[AndyScherzinger]

So yes it is something like leading edge and bleeding edge

[skymania]

Fancy seeing you all here :D mostly glad :+1:

[AndyScherzinger]

Just mostly @skymania ? Should I send you a team invite? :)

[AndyScherzinger]

@tobiasKaminsky I'll try to redefine my three terms :)

• stable = Play store and f-droid releases for the masses
• release candidate = tested PRs, merged to to master between stable releases, published on the Play store beta channel
• beta = your awesome beta application that can be installed in parallel and contains PRs that are done in development but not necessarily to be considered stable enough for master or might even still have known bugs

example for stuff put in beta but not in the release candidate: the new drawer implementation. It works for newer Android versions but the account switching doesn't work on at least one Android 4.x device as reported. So we would not publish it so a larger user base but to the beta app for users who are willing to help us out with testing and reporting issues.

Regarding the labels: @schiessle configured the labels, so we now have a larger list at our disposal :+1: Thanks!

[skymania]

@AndyScherzinger ok very glad ;) no need, already in :)

[AndyScherzinger]

We now have the following labels, @ all - anything missing from your point of view?

1. to develop
2. developing
3. to review
4. to release
   approved
   beta
   bug
   design
   enhancement
   help wanted
   high
   low
   medium
   need info
   start issue

[AndyScherzinger]

How do we want to progress here?

Just an idea

1. I update the guidelines according to the discussions we had so far and ping this thread here
2. Anyone willing and interested can do a review, we can discuss necessary changes and misunderstanding and update the guide lines
3. After we came to terms for an initial version 1.0 I will convert it to an md file and put it into the repo

It would then be an initial version which which of course still change over time and adapt to lessons we learned done the road but should be enough for anyone new to the project to understand how development is done here from a high level perspective. Things we will probably link to when we have would be things line code formatter setup, etc. etc.

Sounds good? - I will probably not find the time to update the guide before Sunday (or later).

[tobiasKaminsky]

After an internal discussion with @AndyScherzinger we suggest to handle new PRs in this way:
(of course this is just a discussion base and is not fixed)

• every new PR where the developing is finished will be merged into f-droid beta by me
• release cycle
  
  
  
  • for each release we choose several PRs that will be included in the next release
  
  
  • these will be merged into master, tested heavily, maybe automatic testing
  
  
  • after feature freeze a public play store beta is released
  
  
  • ~2 weeks testing, bug fixing
  
  
  • release final version on f-droid and play store
  
  

Feedback and ideas are more then welcome

[tobiasKaminsky]

@LukasReschke regarding play store beta

[tobiasKaminsky]

We should really going on with this...

[AndyScherzinger]

Absolutely!

[tobiasKaminsky]

I'll do this now :+1:

[tobiasKaminsky]

Let us discuss in the PR: #68