So I got the script written that does different types of releases, yet I can’t for the life of me figure out how to deal with the changelog. It seems teamcity does not support multiline text inputs like jenkins did.
@AudriusButkevicius Should I go ahead and restrict F-Droid builds to
No, we’ll do 0.0.0-beta0 for betas.
Sorry, you lost me there. Do you therefore want any tags built on F-Droid?
No, the stuff that is there is ok.
Commit: 0.10.13+3bd1c753a68aea079c0be08152ecd7c8b55273f7 (built from official master)
APK version: 0.10.14.beta Syncthing version: 0.14.50.rc1
https://github.com/syncthing/syncthing-android/pull/1211 Add “receiveonly” folder type to UI and model (fixes #1210)
https://github.com/syncthing/syncthing-android/pull/1209 Root only - Temporarily increase fs.inotify.max_user_watches to 128K (fixes #1208)
@Catfriend1 So, eh, what’s this a beta of? Again, “beta” implies a procession from something like alpha/master/dev -> beta -> release. Will there be a release of 0.10.13+3bd1c753a68aea079c0be08152ecd7c8b55273f7 if that commit passes muster? Called what? Is this materially different than the 0.10.14-beta1 just tagged by Audrius? You guys need to sort this out or this makes no sense.
We can’t have commit-free beta vs release like syncthing because:
- Updating syncthing between RC and real deal requires a commit
- Any new version published to Gplay requires a magic integer incremented.
- The actual version of the app is in one of the files which has to be updated in order not to be a beta.
Yet I intend the next release to be whatever is currently on beta1 + whatever commits we need to get it into gplay with the right version strings.
I have no issue with that. It’s the same code with a couple of build metadata tweaks. Syncthing does essentially the same, we just piggyback the build metadata on the tag name and handle it magically in the build scripts.
But I’d still like some coordination here. Catfriend1 calls
3bd1c75 0.10.14.beta, you call
7279ac7 0.10.14-beta1. Your version contains at least updated translations and a bumped Syncthing dependency. Apparently the Catfriend1 edition also contains Syncthing 0.14.50-rc.1, although the source tree at that commit actually points to 0.14.49.
Both cannot reasonably be “betas” of 0.10.14, since they are different. Yours wins in my opinion, by way of having a tag, actually pointing to the included Syncthing version and being semver. That makes the other one just a build of master. But then it’s not a beta, official or otherwise.
So, please coordinate and cease the unofficial beta stuff if there is an official beta, or something.
He should just stop calling his debug build betas, call them debug builds, and we should release betas properly to the play store.
Well, yes. The build server produces apk:s of each commit to master. The builds are out there for the willing, to test. The beta should be something specific released in the normal manner.
To clarify my beta version doesn’t have the translations. The syncthing 14.50rc.1 got in there without a commit by placing the source into the required directories and taking the built libsyncthing.so files over to the android build. Hmm yes its got quite confusing now. If Audrius likes to push the beta button lets say roundabout once every two weeks when there were pull requests thats enough and I don’t need this thread anymore for an unofficial build.
It’s an accepted an merged PR beta and was just released. This debug build replaces my APK mentioned above also including the translations and version number bump to 0.10.14-beta.1 : https://build.syncthing.net/repository/download/SyncthingAndroid_Build/25018:id/apk/debug/app-debug.apk
Sorry I didn’t check the forum recently, so I’m a bit late to this thread (and I’m not sure if I got everything right). The way I understand it, Google Play gives these options for beta releases:
- Make a
-betarelease and publish it on the beta channel, then later build a new, final version with different
versionNamefor the release channel.
- Put the normal release on the beta channel, and promote it to the release channel via Google Play if there are no problems after a few days.
F-Droid also supports beta releases, but last I heard, only F-Droid maintainers can declare a version as beta (this might have changed in the mean time). Other apps like Nextcloud have a separate listing for the dev version: https://f-droid.org/en/packages/com.nextcloud.android.beta/
Also, I agree that any releases (including beta) should be triggered manually. Releasing betas automatically seems to risky to me. And using a fork for beta releases also sounds bad to me, it should all come from master.
By the way I finally have some time for coding again, so I could help with this. I just don’t have a fast laptop, but that’s not a problem if I can use a build server.