-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Development Guide discussion #7
Comments
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). |
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... |
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... |
As this guide will change only in the beginning I am fine with a file. Some open questions I have:
This should be added to make clear that every idea should be discussed prior to implementing it. Developing roadmap:
|
Sounds good to me, so let's finish up an initial version in the wiki and then put it in the Repo |
Next question: who should merge? Anyone or the pr opener as he/she can verify it a last time? |
Good point, with two thumbs up we should be fine with anybody merging. |
Next question: which labels? Same as ownCloud? |
I would suggest just having a label for approved issues: "approved" |
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.
The easy answer is: When they are ready ;) My Question + opinion
|
@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? |
"approved" should be an independent label to not confuse us ;) Issue: |
What do you think about the guidelines on when changes should go into each release channel and the steps to prepare for stable releases? |
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. |
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" |
alpha is more unstable than beta, at least for me. |
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. |
So yes it is something like leading edge and bleeding edge |
Fancy seeing you all here :D mostly glad 👍 |
Just mostly @Skymania ? Should I send you a team invite? :) |
@tobiasKaminsky I'll try to redefine my three terms :)
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 👍 Thanks! |
@AndyScherzinger ok very glad ;) no need, already in :) |
We now have the following labels, @ all - anything missing from your point of view?
|
How do we want to progress here? Just an idea
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). |
After an internal discussion with @AndyScherzinger we suggest to handle new PRs in this way:
Feedback and ideas are more then welcome |
@LukasReschke regarding play store beta |
We should really going on with this... |
Absolutely! |
I'll do this now 👍 |
Let us discuss in the PR: #68 |
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
The text was updated successfully, but these errors were encountered: