Cloudron updates
-
@girish How about allowing users to auto-update Cloudron X days after a new release is available? For example, some people might choose 2 days, others 10 days, and still others 30 days.
I will be intentionally harsh because you guys seem arrogant and ignorant.
The lack of this simple yet valuable feature is one of a plethora of examples of Cloudron's very poor marketing. Marketing? Yes! That feature is a marketing feature because it enables customers to say, "Oh wow! Instead of a bunch of myopic, arrogant, and self-centered nerds running this project, this company seems to actually care about the user experience."
For Cloudron to grow faster, you guys need to improve your marketing.
-
@yeku that escalated quickly in tone for no apparent reason.
If you miss a feature or something isn't clear, like what "unstable release" in the Cloudron context means, you may just ask, and we will try to sort things out.
@nebulon First, see https://forum.cloudron.io/topic/8939/i-suggest-you-offer-scheduled-phone-call-video-call-technical-support-in-english-for-x-us-dollars-per-hour I am displeased that I haven't received a meaningful response yet.
Second, "For the others, it says the release is unstable because we want to discourage them from updating it." is inane and ignorant. Up means up, down means down. One should not indicate "up" when one means "down." We aren't communicating using Cloudron's super special version of English on this forum. We are using standard English. Don't call a release unstable if it's not unstable. Why not simply follow my sage advice and allow users to choose the number of days before auto-updates are applied?
Third, "there's already a way to set the update schedule - https://docs.cloudron.io/updates/#update-schedule ?" is precisely the sort of ignorant and arrogant response I deplore. My suggestion was much better, yet it was not properly addressed.
Here's the current marketing slogan you guys seem to be currently embracing, "Hi, we're Cloudron! We do things the way we like; we blithely ignore excellent user suggestions because well, ummmm, errrrr, we are ignoramouses!"
-
@nebulon First, see https://forum.cloudron.io/topic/8939/i-suggest-you-offer-scheduled-phone-call-video-call-technical-support-in-english-for-x-us-dollars-per-hour I am displeased that I haven't received a meaningful response yet.
Second, "For the others, it says the release is unstable because we want to discourage them from updating it." is inane and ignorant. Up means up, down means down. One should not indicate "up" when one means "down." We aren't communicating using Cloudron's super special version of English on this forum. We are using standard English. Don't call a release unstable if it's not unstable. Why not simply follow my sage advice and allow users to choose the number of days before auto-updates are applied?
Third, "there's already a way to set the update schedule - https://docs.cloudron.io/updates/#update-schedule ?" is precisely the sort of ignorant and arrogant response I deplore. My suggestion was much better, yet it was not properly addressed.
Here's the current marketing slogan you guys seem to be currently embracing, "Hi, we're Cloudron! We do things the way we like; we blithely ignore excellent user suggestions because well, ummmm, errrrr, we are ignoramouses!"
@yeku if you have feature requests or suggestions, we have a forum category for this at https://forum.cloudron.io/category/97/feature-requests
As you will see, there are lots of things on our list which are of different priority for the various different use-cases our users have. Of course ideally we have time for every request asap, but that is not how it is.
To avoid further unexpected updates in your case, you can also completely disable automatic updates.
-
@yeku if you have feature requests or suggestions, we have a forum category for this at https://forum.cloudron.io/category/97/feature-requests
As you will see, there are lots of things on our list which are of different priority for the various different use-cases our users have. Of course ideally we have time for every request asap, but that is not how it is.
To avoid further unexpected updates in your case, you can also completely disable automatic updates.
-
@girish Yep, don’t feed the troll.
-
I am a bit annoyed this post got overrun.
I want to make it clear that I am not chastising or belittling.
I am just hoping to have either further clarification or a feature added to delay the "Unstable" releases.
I understand that unstable doesn't mean that something is being rolled out on purpose that is going to break everything, but I operate solely a prod server, not a dev environment. So having an unstable rollout can be detrimental.
I am essentially hoping for some assistance as to how to navigate this
I am open to any ideas or suggestions
-
I am a bit annoyed this post got overrun.
I want to make it clear that I am not chastising or belittling.
I am just hoping to have either further clarification or a feature added to delay the "Unstable" releases.
I understand that unstable doesn't mean that something is being rolled out on purpose that is going to break everything, but I operate solely a prod server, not a dev environment. So having an unstable rollout can be detrimental.
I am essentially hoping for some assistance as to how to navigate this
I am open to any ideas or suggestions
@privsec no worries, let me clarify this a bit more and maybe you can tell us if any changes are to be made.
-
When we make a release, it's already pretty well tested. We don't do beta/alpha releases. We also don't publish a release which is half baked. As you know, Cloudron instances are totally stand alone and we don't have access to people's servers. Most of them also auto-update. This means that releasing something untested will hose servers left and right. This will be catastrophic for us.
-
Now we have gazillion Cloudron installations. If we make a release available to everyone at the same time, then the support burden for us too high even if say 100 servers fail to update properly. For whatever reason - disk space, some DNS issue, nodejs release tarball couldn't be downloaded, docker hub is down etc.
-
For this reason, we roll out releases slowly. The strategy is simply to roll these out alphabetically (domain name based) over the course of a month or so. In the past, a release was not "visible" to others. For example, if we are rolling out "a", then people with domain starting "t" cannot even see the release and cannot update.
-
We were told, people wanted to apply an update and help test and they couldn't wait. For this reason, we allowed domains starting with "t" to update, but it will show a warning that this is a pre-release and unstable. This simply prevents non-enthusiasts (specifically, 99% of cloudron users, who are not on this forum and haven't read all these things and never will) from updating. This message needs to a bit scary, otherwise from our experience they will update.
Happy to clarify further. I am not sure what behavior is wanted at this point. Is it that you don't want to update until all other Cloudrons in the world have updated? Even we don't know/keep track when all Cloudrons updated. Only idea I can think of is to disable automatic updates and update when you see a blog post from us about the release or something like that.
-
-
@privsec no worries, let me clarify this a bit more and maybe you can tell us if any changes are to be made.
-
When we make a release, it's already pretty well tested. We don't do beta/alpha releases. We also don't publish a release which is half baked. As you know, Cloudron instances are totally stand alone and we don't have access to people's servers. Most of them also auto-update. This means that releasing something untested will hose servers left and right. This will be catastrophic for us.
-
Now we have gazillion Cloudron installations. If we make a release available to everyone at the same time, then the support burden for us too high even if say 100 servers fail to update properly. For whatever reason - disk space, some DNS issue, nodejs release tarball couldn't be downloaded, docker hub is down etc.
-
For this reason, we roll out releases slowly. The strategy is simply to roll these out alphabetically (domain name based) over the course of a month or so. In the past, a release was not "visible" to others. For example, if we are rolling out "a", then people with domain starting "t" cannot even see the release and cannot update.
-
We were told, people wanted to apply an update and help test and they couldn't wait. For this reason, we allowed domains starting with "t" to update, but it will show a warning that this is a pre-release and unstable. This simply prevents non-enthusiasts (specifically, 99% of cloudron users, who are not on this forum and haven't read all these things and never will) from updating. This message needs to a bit scary, otherwise from our experience they will update.
Happy to clarify further. I am not sure what behavior is wanted at this point. Is it that you don't want to update until all other Cloudrons in the world have updated? Even we don't know/keep track when all Cloudrons updated. Only idea I can think of is to disable automatic updates and update when you see a blog post from us about the release or something like that.
@girish speaking for myself, I’d love the ability to auto-update apps (or set it based on each app so some won’t auto-update) while keeping the actual Cloudron server version a manual update. Not sure if that’s a good idea or not but I’d rather allow some to update and others to not. Much like I mark some plugins as “trusted” in MainWP for managing all my WordPress installs where it auto-updates within 48 hours, and some plugins as “untrusted” which means it requires manual intervention before updating. That same concept could maybe be applied within Cloudron.
But otherwise I think it’s not too bad the way it is… if people don’t like auto-updates then disable it. Simple as that. But I do think there could be improvements to the update mechanism to allow for more granularity.
PS - sorry you have to deal with the occasional a**hole like ‘yeku’ above. They do not represent the vast majority of us who are very happy a project like Cloudron exists in the first place.
-
-
@privsec no worries, let me clarify this a bit more and maybe you can tell us if any changes are to be made.
-
When we make a release, it's already pretty well tested. We don't do beta/alpha releases. We also don't publish a release which is half baked. As you know, Cloudron instances are totally stand alone and we don't have access to people's servers. Most of them also auto-update. This means that releasing something untested will hose servers left and right. This will be catastrophic for us.
-
Now we have gazillion Cloudron installations. If we make a release available to everyone at the same time, then the support burden for us too high even if say 100 servers fail to update properly. For whatever reason - disk space, some DNS issue, nodejs release tarball couldn't be downloaded, docker hub is down etc.
-
For this reason, we roll out releases slowly. The strategy is simply to roll these out alphabetically (domain name based) over the course of a month or so. In the past, a release was not "visible" to others. For example, if we are rolling out "a", then people with domain starting "t" cannot even see the release and cannot update.
-
We were told, people wanted to apply an update and help test and they couldn't wait. For this reason, we allowed domains starting with "t" to update, but it will show a warning that this is a pre-release and unstable. This simply prevents non-enthusiasts (specifically, 99% of cloudron users, who are not on this forum and haven't read all these things and never will) from updating. This message needs to a bit scary, otherwise from our experience they will update.
Happy to clarify further. I am not sure what behavior is wanted at this point. Is it that you don't want to update until all other Cloudrons in the world have updated? Even we don't know/keep track when all Cloudrons updated. Only idea I can think of is to disable automatic updates and update when you see a blog post from us about the release or something like that.
@d19dotca said in Cloudron updates:
@girish speaking for myself, I’d love the ability to auto-update apps (or set it based on each app so some won’t auto-update) while keeping the actual Cloudron server version a manual update. Not sure if that’s a good idea or not but I’d rather allow some to update and others to not. Much like I mark some plugins as “trusted” in MainWP for managing all my WordPress installs where it auto-updates within 48 hours, and some plugins as “untrusted” which means it requires manual intervention before updating. That same concept could maybe be applied within Cloudron.
But otherwise I think it’s not too bad the way it is… if people don’t like auto-updates then disable it. Simple as that. But I do think there could be improvements to the update mechanism to allow for more granularity.
PS - sorry you have to deal with the occasional a**hole like ‘yeku’ above. They do not represent the vast majority of us who are very happy a project like Cloudron exists in the first place.
I would like something like this.
-
-
@d19dotca said in Cloudron updates:
@girish speaking for myself, I’d love the ability to auto-update apps (or set it based on each app so some won’t auto-update) while keeping the actual Cloudron server version a manual update. Not sure if that’s a good idea or not but I’d rather allow some to update and others to not. Much like I mark some plugins as “trusted” in MainWP for managing all my WordPress installs where it auto-updates within 48 hours, and some plugins as “untrusted” which means it requires manual intervention before updating. That same concept could maybe be applied within Cloudron.
But otherwise I think it’s not too bad the way it is… if people don’t like auto-updates then disable it. Simple as that. But I do think there could be improvements to the update mechanism to allow for more granularity.
PS - sorry you have to deal with the occasional a**hole like ‘yeku’ above. They do not represent the vast majority of us who are very happy a project like Cloudron exists in the first place.
I would like something like this.
-
I think the current roll out strategy (auto-update alphabetical with the possibility to manually update) is very flexible on both Cloudron end and user end and so makes perfect sense. However it seems like some people running prod servers may be worried about bugs introduced in new major or minor releases. And it is true that at least the first patch release iron out the biggest annoyance introduced in new major/minor releases.
Personally as a maintainer of several instances, I would like to still have auto-update enabled (so I don't have to remember to do it), but for the most sensitive instances be able to wait until some of the bugs have been found by early tester and iron out by Cloudron Super Hero Devs
So, as well as what @d19dotca proposed, would it be possible to add a platform update option to auto-update platform only after the first patch release (so basically auto-update except for version x.y.0)? (Like Cloudron does with Nextcloud where major release updates are pushed only after the first patch release)
Hell my brain fused reading Yeku's posts, @girish @nebulon sorry you had to deal with that, FWIW I'd like to say that it feels to me you have definitely built a strong community of happy users around your software and it felt we're all working here as part of a big team.
-
G girish marked this topic as a question on
-
G girish has marked this topic as solved on
-
G girish referenced this topic on
-
A avatar1024 referenced this topic on
