as a consequence of the discussion in topic ( Folder creation broken in Android app ) and recurring questions on the github issue tracker why things that have been fixed by commit are still broken in the release version, I’d like to offer help for people that don’t mind installing a beta build on their phone. I understood that @AudriusButkevicius doesn’t have the time to build releases and beta’s repeatedly. Currently, a lot of development is going on regarding Syncthing Android and I need the early feedback from users to find bugs or improve feature enhancements that don’t fit to everyone for a reason.
How can you get support for the beta?
This version lives only within this thread, so if you’d like to provide feedback, please do it here mentioning which version you downloaded. If your feedback is also relevant for the official master, I’ll carry it over to the issue tracker.
Switching between release and beta?
To switch from release to beta, please open the release app first. Head to the options menu on the left drawer, open sub menu “Backup” and export your settings. Then, please make sure you exit the release app (best way is to force-close it). After that, you can install the beta app from the download link below (requires “unknown sources” to be enabled in Android). Start the beta app, head to the options > “Backup” menu > “Import configuration”.
Disclaimer
My intention here is to offer a “ready-to-use” syncthing-android app and working updates to it. Even though I’m only building this with having well thought about which code is safe and which should wait to get into the beta, I am not taking any responsibility if you did not do backup your data first or in case you even lose data. If you want to use a release grade syncthing-android, please head to google play or f-droid for the official releases.
This is not, then, a beta of the thing that will actually be released at some point - more a “Catfriend1 edition” that is different from the official version?
@calmh My intention is to build it from the officially approved and commited code in the github.com/syncthing/syncthing-android master. I’m not bringing new code in on my own. If I have new code, I’ll continue to open pull requests to the master repo. The reason why I’m building from github.com/Catfriend1/syncthing:buildBeta “fork” is that I need ten lines of the build script changed so I get a new package id for android (com.nutomic.syncthingandroid.beta).
So, yes, the code I used to build is already on the official syncthing-android master and will get released sometime.
I cannot use com.nutomic.syncthingandroid as this would conflict with Audrius’ releases and as I don’t have the proper signing keys to use this specific package id.
The “official beta” channel is also locked as I don’t have permission there to assit Audrius.
Right, so we may be talking past each other. “Cherry picked commits” to me means divergence. “Beta” means a certain commit hash is first released as v1.2.3-beta and then, once it’s proven itself, released again as v1.2.3 without any further changes. You seem to be wanting to do the latter, which sounds fine to me, but also means there’s no cherry picking involved.
(That there is currently a diff for the beta suffix and whatever build fixery is beside the point.)
The reason I’m being picky about this point is that it is the difference between a beta and a fork. A beta we should assist with and coordinate, I think. A fork you are welcome to do, but that’s your thing then.
If you (the collective you as in the people who do the Android thing) want to do betas I think the first thing to do is to decide on a release schedule / policy of some kind. This is what Syncthing does.
And of course, releasing commit A as v1.2.3-beta and then a different commit B as v1.2.3 defeats the point entirely as there may be any number of new regressions between A and B. So the beta releases and the regular releases really need to be coordinated.
It’s actually easier with Android. As you release 0.10.95 (as in a real release), just don’t roll it to the production channel, it lands in beta. If that is fucked, you release 0.10.96 to the beta channel, and if that did not break the planet you roll that to prod. The only difference is that fdroid will pick up all this garbage along the way as prod. I think we might have to mark these as pre-releases in github, and mark them as real releases once we put it on the prod track in gplay, meaning we need a magical script for that.
Does f-droid do its magic as soon as you create a tag, or can you just avoid creating a GitHub release until it’s time for a stable release?
Otherwise it sounds like all pieces are in place. I still suggest you decide on a schedule and stick to it, barring disasters. I.e., something like our “stable release every first Tuesday of the month, beta the week after”.
I just tried this build:
2018-08-03 BETA 0.10.13+6a04d640bd0c7dcded028d39a162fb0fa6166127
and created a new test directory on my external SD card (storage permission granted). This is on a LineageOS (Android 7.1.2) device.
It created the new directory just fine using the SAF framework and then says:
“Your Android version only grants Syncthing readonly access to the selected folder” in the folder settings page.
Let me know if there is anything I can do to assist you in debugging this.
P.S. F-Droid can work in “manual-only” mode, on any new commit or looking for tags with a certain version numbering scheme AFAIK. There is also a way to automatically distinguish “beta” and “stable” releases based on this.
@spaetz If the message says android treats this directory read-only that’s correct. It’s an android limitation that even if you’ve granted storage permission the android os will force the directory to be readonly for the syncthing (native linux binary). This problem has been written up a lot of times and is mainly coming from the go binary not having appropriate ability to communicate read-write permissions to android SAF. You can workaround with:
using root privileges
placing the directory on extSdCard/Android/data/com.nutomic.syncthingandroid.beta/files/[your_folder_name]
@AudriusButkevicius@calmh I’d suggest throwing the beta out every two weeks on friday. I picked this plan randomly you wishes to adjust it are welcome.
@AudriusButkevicius Could you please assist in making the “magic script” as I’ve no permissions to be able to develop and test a script. Maybe we can also put an extended build.gradle like the one in Catfriend1/buildBeta on a branch in the main repo. This would assure to build on the lastest official commit when the master is pulled in before every beta build. (That’s what I’m currently doing on my repo to follow calmh’s guideline to make a beta with stuff later to be officially released.)
Looks like they can be told to just look at tags that match a given regexp, so you could for example let them release tags matching ^fdroid-v([0-9.]+)$ or so.
Or just let f-droid be your beta channel. Hey ho lets go.
@Catfriend1 For what it’s worth, the build process should ideally not differ either. For Syncthing the “betaness” of a release is decided completely by what git describe returns. If the resulting version string contains a dash it’s not a release version. Some other policy could apply for you guys as appropriate.
Making a stable release involves pushing a new tag and rebuilding. From what I understand for Google Play you don’t need even that. The only thing would be maybe a new tag to poke at f-droid.
I run ./prepare-release.sh which updates translations, bumps some number important to google, updates version info, asks for a changelog.
I push these new commits to master, together with the new tag.
I manually run Release Syncthing-Android specifying a commit/branch to build from which rolls it to beta channel
I manually roll beta to prod after some time (or gradually roll out).
In the background, f-droid picks up the tag and builds a version itself.
Essentially I am thinking of doing the following:
Have Release Syncthing-Android job runnable by @Catfriend1.
Change the job to require a changelog upon trying to build. The job itself would run ./prepare-release, pull in translations etc. This would also push a version tag, and land the version in G-Play in the beta channel. Potentially looks for last released version, so that changelog is “accumulating” between all unreleased versions until we actually release (Not sure if it’s possible).
Change f-droid to not pick up generic version tags, but ask them to look for f-droid-123.123.123
Have another Release Syncthing-Android to prod, which checks for the last 123.123.123 tag, checks that that’s the tag (or the other magic number) in the beta channel, if it is, rolls the beta to prod, and tags 123.123.123 tag with f-droid-123.123.123.
The annoying this is that we will have gaps in versions (as in 0.10.99 might be a beta that was never release), but I guess that’s ok.
I can do the F-Droid stuff if you’d like me to. I am already set up to do the necessary changes (it’s essentially just PRing against their metadata repo). Possible only build on tags matching [0-9].[0-9][0-9].[0-9]$ to exclude any .*-beta$ or similar versions or by building on custom tags as you proposed (f-droid-.*).
I asked but didn’t get an answer yet on the f-droid irc about pre-releases. Potentially we could add an exact clone of the existing Syncthing app to the reop except that it’s called e.g. Syncthing-dev (or -beta, …) and there’s no restriction on which tags are built.
A beta we should assist with and coordinate, I think. A fork you are welcome to do, but that’s your thing then.