My understanding is that for example, if I'm currently on Cloudron 5.0.1, and I want to upgrade to Cloudron 5.1.0 before it's "released" officially, I have to contact firstname.lastname@example.org and request it, giving the subscription number and all that jazz.
It'd be great if there was just the ability to force my Cloudron to update early such as through the CLI or through an "unstable" tag option in the Settings page for updates. In other words, somebody should be able to opt-in to unstable builds without needing manual approval.
And I don't suggest this only to benefit the admins of Cloudron, I suggest this would benefit @girish & @nebulon too as you'd be getting less emails from customers for what I assume is a trivial task that could easily be offloaded from your team, allowing you to focus on more important tasks.
Anyways, I'd love to be able to upgrade an environment to 5.1.0 a week early for example so I can run some tests in a lower environment without having to completely redeploy to get it. Hopefully that makes sense.
In the past, we used to have an option to opt-in to unstable releases. We removed it because many would update, something would break and we had lot more support requests than having to send out template emails from support
But now that I think about your suggestion a bit more, I think the mistake in what we had before was that we used to also auto-update to unstable releases (once opted in). Maybe what's needed is a) opt-in to unstable and b) admin has to manually click update. See an update dialog with an warning ("warning: limited timely support") and only then be able to update.
Also, new installations always get the latest (even if a bit unstable) release. This is usually where most of our testing happens (and not existing users). We get many installations each day, so we get a lot of testing with this approach. If you setup a new test Cloudron now, it will get the latest release. It's free anyway and requires no subscription. You can even install it under your existing domain
cloudrontest.foo.com. We prefer this over installing an unstable release on a production system (which is just stressful for everyone).
@girish Setting up a brand new instance was what I was hoping to avoid though. For example, I may be setting up a new Cloudron environment to pretty much only host a public status page app and perhaps some staging apps before migrating to a production Cloudron. In that lower environment, I'd like to perhaps be on the beta builds and manually update rather than having to setup a new instance each time.
I am in full agreement though, that if it was baked into the app for opting-in to unstable builds, that there's a very clear message to users that there is no support for it, a message on how to report bugs/defects, and warning to not install on a production system - for example. That definitely shouldn't increase your support levels if people are understanding of what they're getting themselves into.
And yes, definitely also in agreement that it should be a manual update. If one is using it to test, it can't be a very valid test if the version keeps changing on them. haha