Having a visual way to configure this makes it much more accessible to non-programmers, with error checking available through the host (Excel, in this case), while also reducing the eng effort in building this.
At Google, many internal tools use Sheets as their source of truth for config data, and it works really well.
It's actually refreshing to see end-user documentation and answering the basic questions of “what can this do” and “why should I care” in the readme. Most projects jump straight into how to build it locally, with not even a screenshot of what they’ve created.
This is exactly what staged rollouts are for. The author ignored that best practice. You can halt any release as long as it is in progress. Once you mark it complete (defined as rolled out to 100%), you can’t roll it back.
Each track in Google Play (alpha, beta, canary, prod) can hold up to one release at a time. It would get really confusing if it allowed more than one. And with the other rollout safeguards provided decelopers, it’s quite possible and very easy to do exactly what you’re asking for.
Android as an OS does not support rollbacks. It can only upgrade apps in monotonically increasing `versionCode`s. The simple reason is that client side data may have been upgraded by a newer release to a format that is now incompatible with the old version. Sqlite databases follow the same policy.
This is well-known to anyone who has been doing Android development for a while.
Thank you for creating this! I’ve been looking for an alternative to Jekyll locally, while also sticking to the Jekyll repo format to use with GitHub Pages. (Because the repo format is good enough, and trying to migrate to Hugo was a nightmare on each of the three attempts I made several months apart.)
And a special call-out to your dedication to providing amazing documentation. Caddy is what all projects should aspire to be.