While the fix got merged in the meantime, I think @AudriusButkevicius we should continue the release management discussion on the forum and not in a single PR.
@all: If someone can help us with creating unit tests that somehow no one did since approximately 3 years for the android app, this would be VERY awesome and appreciated. (see https://github.com/syncthing/syncthing-android/issues/385)
Quotes: AudriusButkevicius commented an hour ago
So much for testing I guess.
I think you should start writing automated unit tests, because as we can see manual testing doesn’t scale and catch everything.
AudriusButkevicius commented 20 minutes ago
Talking about software development in a professional fashion, I doubt you’ll find a place where unit tests are optional (unless it’s a complete fucking cowboy place that hires anyone and doesn’t care about going out of business). Writing tests is part of a developers job.
Sure, it’s open-source, we can be sloppy, but I can just not merge stuff until it has some reasonable unit test coverage to prove that it works.
I’d rather have no improvements, over improvements that might just break the app all together just because we don’t feel heroic when we write tests.
Catfriend1 commented 3 minutes ago
@AudriusButkevicius I see your point. It’s like you stated, we are no business so if something is fucked up it gets fixed, the sooner the better! If you can’t live without tests (as syncthing core has them), feel free to contribute them. This is not a valid argument putting the work on me. I think we both wouldn’t be lucky if a fork has to come up to have an easier way to push app development forward and then gets out of sync so multiple app’s would coexist. There are much prettier ways as making a better release and hotfix plan which you disagreed?! before. So this is my suggestion:
- We push everything after reviews and incremental testing took place forward to the master. That’s consuming a lot of time and from my side is okay as we currently handle it.
- The master regulary gets a new beta build pushed to google play “weekly” (+/- some days okay of course as some of us might be busy)
- The “third” beta in the cycle will be uploaded to transifex. (I assume this is roundabout the third week after the last release) People can start translating new stuff to eliminite this “german/english” artifacts in the UI we currently experience.
- The “fourth” beta pushes a new syncthing core version in (when its ready in its regular release cycle) and gets uploaded to GPlay (most translations probably done until then) Beta, because the current handling using the release script to automatically bump syncthing core’s version is not sufficient to eliminite wrapper compatibility errors before release if any come up. I guess “you” (or anyone else) didn’t test the release version after syncthing 0.14.48 got 0.14.49 compiled in before pushing it to google play. It was me doing the testing on my private build server as the master wasn’t even linked to 14.49-rc.4 at an pre-release point in time.
- If the “fourth” beta doesn’t turn out any high-priority issues impacting the major use of the syncthing app, it should get pushed to Google Play as a release after about two weeks.
To sum up: Approximately six weeks after the last android app version release we would finally push out a new release to google play.
If we have an urgent problem like with 0.10.12 and the folder creation, we should discuss if it’s okay to do a hot-fix release only cherry-picking the most important commits from the master related to the hot-fix (as the master might have more merges in-between already).
I’m writing this in the hope “we” find an agreement that empowers the work together without creating too much overhead as we haven’t much active contributing people on this repo at the moment. I would agree on putting more rules on this repo when and how changes get in when the major downsides of the app got fixed and we have more active contributors.