Please don't upgrade docker without asking first

[rfay]

Please don't auto-upgrade Docker Desktop. Or give us an option to disable upgrades like this. It's fine to prepare the new patch. It's fine to simplify the process. But don't just install without giving us some recourse.

Despite the most heroic efforts of the Docker team, a new release may have new bugs. In software we deal with this all the time. All of us face it, and to move forward there has to be some risk.

However, if there's no way to stop auto-upgrades, there's no easy way to go back to the working version.

So Docker Desktop for Mac 3.0.2 has problems that completely break ddev and some other tools, see docker/for-mac#5157. So fine, we need to roll back to 3.0.1 right?

Unfortunately, with the current auto-upgrade approach introduced in 3.0.0, If you install 3.0.1 it will immediately prepare to install 3.0.2. Then when you reboot or restart docker, voila, you have 3.0.2 again, which doesn't work. And there seems to be no way to stop this cycle.

For those with this pain right now: I think installing Docker Desktop 2.5.0.1 is the only solution.

[kinoute]

I 100% agree. 3.0.2 completely broke my volumes, I rollbacked to 3.0.1 which was self-updated again to 3.0.2... Please ask the user to update or make it optional in the settings.

[ebriney]

Sorry about it, we rushed a bit the last update and introduce a severe bug.
I'll try to fix it today and if I cannot, rollback last grpcfuse patches.
On next updates we will do some canary updates.
But the whole goal of auto-upgrading is to avoid the spread versions, it's a mess to investigate when you have reports from 1 year old version, that's the main reason why we choose to do that.
Just for you to understand:

[ThomasNegeli]

@ebriney
We appreciate your hard work in maintaining the software.
I totally agree that the spread of versions is a real problem.
The problem for a developer is, that on one day your local setup might work, and you reboot your machine the other day, and your setup is broken without any hint.
A comparison with a browser version, as @stephen-turner did in docker/for-mac#5119 (comment), is not a practical usecase for a system backing your development workflow.
So please let us choose when we update the client, and don't do the decision for us.

[mehigh]

Blocking outgoing network connections to desktop.docker.com can keep you on on the functional 3.0.1 by not allowing the auto-upgrade to 'find' the broken 3.0.2 version, this can be used as a temporary patch.
You'd need somethling like Little Snitch to achieve it, but at least you won't lose a Monday.

[ebriney]

You can also use 3.0.2 and switch back to osxfs

[mehigh]

Preferences -> Experimental Features -> Turn Off "Use gRPC FUSE for file sharing"

Thanks for the tip @ebriney

[CedricAlb]

Disabling use of gRPC FUSE was not sufficient to fix my ddev environment (composer commands was freezing, web container unable to stop), I had to revert Docker Desktop to v2.5.0.1

[rfay]

@CedricAlb I hope you'll test with the build in docker/for-mac#5157 (comment) - it would be really important to know if it solves your specific problem.

[CedricAlb]

@rfay I just installed this build for testing but no success...
Composer is still freezing here :

my-project-web:/var/www/html$ composer info -vvv
Reading ./composer.json
Loading config file ./composer.json
Checked CA file /etc/ssl/certs/ca-certificates.crt: valid
Executing command (/var/www/html): git branch -a --no-color --no-abbrev -v

And I still have this error when I try to stop any project :

ddev stop
Stopping ddev-my-project-web ...  
Stopping ddev-my-project-dba ... done
Stopping ddev-my-project-db  ... error
 
ERROR: for ddev-my-project-web  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70) 
An HTTP request took too long to complete. Retry with --verbose to obtain debug information. 
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60). 
Failed to pause containers for my-project: Failed to run docker-compose [-f /Users/me/Develop/my-project/.ddev/.ddev-docker-compose-full.yaml stop], err='exit status 1', stdout='', stderr='Stopping ddev-my-project-web ... 
Stopping ddev-my-project-dba ... done
Stopping ddev-my-project-db  ... error

ERROR: for ddev-my-project-web  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)
An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).' 
Removing container: ddev-my-project-web 

Should I create an issue with these details in the ddev github page ?

[rfay]

@CedricAlb this conversation should be in the other issue (#5157) or in DDEV-Local issue queue. If you can tell us how to recreate the issue - full instructions, preferably with a simple example, it can likely get fixed. This doesn't look like any of the reported issues in docker/for-mac#5157, so it may be something new, or of course, something else. I think the best thing would be a new issue either in this issue queue or the ddev issue queue.

[jonesiscoding]

A reasonable compromise to prevent version spread while allowing people some control over when and how updates install would be to allow the feature to be turned off, but either require the update or disable the software after a reasonable period of time. The definition of "reasonable period" of time might be the subject of some debate, of course.

[rfay]

As users we need to be able to control when an upgrade happens. We understand the need of you maintainers to limit the exposure to a thousand versions, but we really do have to know:

• What version might be installed (currently "Update and restart" doesn't give any suggestion of this)
• When an upgrade will happen. We don't want an upgrade to an unknown version just because macOS or Windows decided to reboot.
• What is in the proposed version and why. Apparently the release notes are not automated, as version 3.0.3 was released today and it does not show in the release notes.

We understand your need to control the number of versions out there, but I think you can understand our need for control of when new versions get installed. Thanks!

[Nuru]

Automatic updating is not an acceptable solution to your version spread problem. This tool simply cannot be used if it is subject to failure at any moment. Forcing auto-updates on unwilling developers will backfire on you. They will either roll back to v2.5.0.1 and stay there until you change your mind, or install Little Snitch to block your automatic upgrades (which will also block your telemetry feed). I almost placed an order for Little Snitch yesterday, but decided to wait a week or two for you to change your minds about this.

You can address version spread by disabling the ability to upload diagnostics from non-current versions, closing issues opened with old versions, and other ways to simply say "we only support the current version, and if you are not on the current version, we are not going to talk to you". Maybe that sounds harsh, but what you are actually doing by forcing version updates on people is even harsher. Not only are you saying "we are not going to talk to you", you are saying "we are not even going to let you run old versions".

Keep the auto-update feature. Allow people to turn it off. Allow people to select which version (of some reasonable number of past versions) to run so they can be secure in the ability to roll back if they have problems with the new version.

[Nuru]

Sorry about it, we rushed a bit the last update and introduce a severe bug.
But the whole goal of auto-upgrading is to avoid the spread versions, it's a mess to investigate when you have reports from 1 year old version, that's the main reason why we choose to do that.

@ebriney Another reason besides https://github.com/docker/for-mac/issues/5163#issuecomment-749283618 that automatic updates is not a solution to your problems is that with automatic updates, any bug that you release becomes an urgent production issue affecting all your users. You need the edge and stable channels and you want to be able to tell people to use an old version while you work on fixes for problems in the current version. The idea that somehow you will be able to do what no one else can do and guarantee you will only release bug free code is just fantasy. No one expects you to be perfect. What we all expect is that you will give us some ability to carry on when bugs make it into a release, and not break our big presentation because we had to reboot our laptop an hour before it.

[EFvS]

Auto-upgrading to avoid the spread versions is nice, but a reliable working setup is important too. An option to disable auto-upgrading would solve this problem.

[jonesiscoding]

An additional point regarding the automatic upgrades is that not all users that run Docker have admin rights on the machine they are using. The machine may have been configured by a systems administrator, or even by a MDM tool. When the software prompts them to download the new update, it then asks for admin rights to install (naturally), which the user does not have.

Even if the ability to disable or delay updates was in the Experimental section, that would be a big help.

[stephen-turner]

Before doing this, we looked at lots of other programs, and this model is very common. Obviously it's universal for web software, but it's common even for other installed development tools such as GitHub Desktop. Our thought was that if it makes sense for GitHub, it makes sense for us. If you disagree, I would genuinely like to understand whether you see Docker Desktop as being in a different category from GitHub Desktop, and if so why.

[stephen-turner]

Also I'm going to move this into the roadmap, as it's a feature request not a bug.

[ThomasNegeli]

@stephen-turner
If Github Desktop is broken, I can switch to a different GIT tool as a workaround.
Also if a Browser is broken, I can temporary switch to a different one.
If Docker Desktop with auto update is broken, I can go home and wait until you fix the problem. My customers will love me for that.

[jonesiscoding]

I have installed Github Desktop to see how it handles automatic updates, when the user is not an admin user and doesn't have write access to /Applications. Unfortunately, I probably won't be able to answer the question until they do a new release, unless someone has a link to a previous version that I could try.

While these aren't all specific differences, as @stephen-turner asked for, these are the main issues I can see with the present setup of not having the ability to either delay or disable the update prompt:

• Docker Desktop fills a role that cannot be easily duplicated from the command line, as most git functions can.
• The user receiving the prompt might not be an admin user, and therefore may not have the ability to install the update.
• Docker Desktop is more complex than Github Desktop. While it's certainly possible that an update to Github Desktop might be designed to work with a new major version of Git, and therefore require external changes, I would guess this would be a rare occurrence. Due to it's complexity, Docker Desktop may contain changes that would require the user to change their container, docker compose configurations, mount points, or related scripts. If an update installs with an single click, with no opportunity to review release notes or delay the update (other than clicking No every time), then the user is forced to make any required changes in 'real-time' rather than completing the task they are already working on.

@stephen-turner, I would be happy to file a feature request regarding verifying that the user is an Administrator prior to prompting for an update, if you think that would be helpful to the discussion.

I would also be happy to file a separate feature request for the ability to specify a preference to delay the installation of new versions for X days, with a reasonable maximum timeframe.

[Nuru]

Also I'm going to move this into the roadmap, as it's a feature request not a bug.

@stephen-turner I suggest you could and should have posted "auto-update" as a feature request before surprising the user base with it, and you would have seen the wide lack of support for it if presented as a no-opt-out feature. No user was requesting forced auto update, which is why I opened docker/for-mac#5119.

Before doing this, we looked at lots of other programs, and this model is very common. Obviously it's universal for web software, but it's common even for other installed development tools such as GitHub Desktop. Our thought was that if it makes sense for GitHub, it makes sense for us. If you disagree, I would genuinely like to understand whether you see Docker Desktop as being in a different category from GitHub Desktop, and if so why.

I only know of 3 desktop tools that force auto-updates on you:

• Google Chrome, which I stopped using because of this
• GitHub Desktop, which I never used because of its limitations
• Lens, which I use a convenience, but can always fall back to kubectl and other command line tools.

As for browsers, Firefox, Safari, and Opera all give you ways to avoid updating if that is what you want. Firefox also provides a very stable ESR version (which I use) which has few and infrequent updates. I don't know how Safari gets tested, but it does not get updated until I explicitly update it and I have never had it break due to an update. The process of getting an update into any of the browsers besides Safari is that new features and bug fixes are tested on a developer channel, promoted to an early adopter channel, and after being found to work in both those channels, by volunteers who expressly opted into testing unstable versions, the change gets promoted to the production channel using a canary deployment, and after passing that gets rolled out widely. So unlike with Docker for Mac, which has had significant bugs in every one of its past 5 production releases, serious bugs in browser production releases are genuinely rare. When serious bugs do get released, the browser teams have the capability to quickly patch them or roll back the breakage. Docker for Mac does not have that kind of system in place. (That is not a criticism of the Docker team in general, as it is very hard to do and not generally expected, but on the other hand it is a prerequisite for forcing users to accept updates.)

GitHub desktop is a convenience tool. It slaps a nice Graphical User Interface on a bunch of stuff, but it is in no way production critical, as evidenced by my happily doing GitHub-centric development without using it. I can do everything I need to do from the command line. I can do most of what I need to from within my IDE. I use a different tool for a graphical UI to Git, again one which only updates when I tell it to, and when it fails (which happens from time to time) I can go and use the Git command line. Since I do not use it, I cannot speak to their track record of releasing bug free code, but I suspect it is better than Docker for Mac's.

If Git fails, which actually happened when git v2.22 was released and dropped support for the filter specification --filter=sparse:path=, I can roll back to an earlier version of git, which I did at the time. Note that this was a fail that was not a bug, but rather dropping a feature some tools relied on.

I am not happy that Lens auto-updates and I have told them about it. They are in the process of making it optional (see lensapp/lens#1831).

The critical difference between all those tools and Docker is that I have no replacement for Docker and it is integral to my day-to-day work, which is a combination of building Docker image and running Docker containers. If Docker Desktop with auto-update fails, what am I supposed to do to keep being able to work, do demos, and so on? This is not a rhetorical question, I want to know because I need to be able to keep working in the face of docker/for-mac#5164, and when I ran into that as a consequence of rebooting my computer to install an Apple update, I had no idea how I was going to continue working. My entire work day was hijacked into finding the cause of the problem, reporting it, and finding a workaround. The fact that I did not have another option is exactly the reason the forced update is not acceptable.

[rfay]

It's not a subtle difference that Docker Desktop is a full system, not just a front-end on another system. So the noted comparison items that do automatic invisible automatic updates are front-end type tools, like Chrome or Github Desktop. Those are tools that let you drive a back-end system, like a webserver or a git server or github. If they break, there are lots of replacements for them. The fundamental back-end functionality is elsewhere, though.

A more appropriate comparison for Docker Desktop would be MariaDB (which certainly doesn't auto-update itself, and couldn't, for stability reasons), or macOS (which is happy to do auto-updates, but only if you opt in.).

I certainly understand the need that drove the auto-upgrade feature, but IMO it's not a match for the type of product that Docker Desktop is, and it's certainly not a match to what we as users want in terms of predictability.

This problem can be fixed simply though IMO by

1. Allowing opt-out. Pestering is OK.
2. Showing the version that will be upgraded to in the "upgrade and restart". Just "Upgrade to and restart"

[citizen-stig]

@ebriney
That's fair point about limiting number of versions, but please do not forget, that experience of user is more important that convenience of developer.

[SamuelMS]

Encouraging users to update promptly, presumably so that you don't have to support old versions, right?

Can't you just not support old versions? Why do you have to annoy your users into updating?

There's probably still some overhead for ticket triage. I'd imagine they get bombarded with help requests, so I can see the value in limiting scope there.

I would push for weekly notifications rather than daily ones.

[cweagans]

There's probably still some overhead for ticket triage. I'd imagine they get bombarded with help requests, so I can see the value in limiting scope there.

Sure. Totally understandable problem. It's also easily automated for this specific thing. Enforce use of an issue template that includes somewhere to put the version. If the version isn't the newest or maybe even newest minus 1, auto-reply and close the issue. If the issue doesn't follow the template, either auto-close it or flag it for manual review.

[stephen-turner]

Also, it’s 11pm on Friday evening here and I’m logging off until Monday, so don’t expect any replies from me for a couple of days.

[SamuelMS]

There's probably still some overhead for ticket triage. I'd imagine they get bombarded with help requests, so I can see the value in limiting scope there.

Sure. Totally understandable problem. It's also easily automated for this specific thing. Enforce use of an issue template that includes somewhere to put the version. If the version isn't the newest or maybe even newest minus 1, auto-reply and close the issue. If the issue doesn't follow the template, either auto-close it or flag it for manual review.

That's assuming all their triage is in this repo, rather than by email, chat, or other forms of direct contact by customers and free users. You don't want engineers triaging tickets as level-one support, but I'd hazard a guess that's what is happening now to an extent – and that Docker is pushing so hard for auto-updating because they're losing velocity / missing targets as a result.

Anyway, I don't mean to play devil's advocate so hard here. I'd be happier with the old model too, but I want to find an equitable solution for both parties where possible. Auto-updates are already disabled now, and that's a win, so now I'd just be happy with reducing the notification frequency so I don't need to think about something out of my control as much.

[dieucao]

Looking at some of the feedback/confusion folks have had about the "Skip this update" button, as @stephen-turner mentioned above, we'll look to make it a bit more clear that you don't have to be a Pro or Team user in order to dismiss the reminder and aren't forcing people to be a Pro user in order to not install a particular update.
I'm currently thinking of adding the word "Snooze" next to the X on the upper right of that dialog.

Regarding why we want to encourage folks to update, there are a lot of ingredients to it, some of which others have stated, such as the support requests/burden, but also the amount of effort required to maintain sensible/working upgrade paths.
Folks might delay one month or three months or even longer before picking up a new update and which then results in a wider set of "from" versions, also increasing support burden.
There are a lot of different strategies folks have chosen to mitigate that, but for our team, we've chosen to try to encourage folks to stay closer to latest so we don't have to look back so far when thinking of potential issues with upgrade paths from a longer tail of "from" versions which then keeps us from being able to move forward quickly.

I worry that if we make the reminders too infrequent for the majority of users, that the issues that crop up in the trailing "from" versions will keep us from moving forward as the tech stack continues to evolve and as we as a company are trying to deliver new valuable experiences to more developers that they feel justifies paying for a subscription.

Like @stephen-turner, I'm also at the end of my work week, and will check back on Monday.

[iMonZ]

@iMonZ Auto-update has been removed in 3.3.0.

Still I can’t untick the auto update checkbox

[jsmythsci]

@iMonZ As of 3.3.0 you cannot deselect "Automatically check for updates" unless you are a Teams member but Docker will not automatically download or install updates. If a new version is discovered Docker will notify you about the new version but it will be up to you if/when the new version is downloaded and installed. Like you, I use an external package manager to manage my Docker install (Chocolatey rather than brew) so I view the Docker notifications as reminders that I need to check for updated versions of all of the things I manage via Chocolatey. In your initial post you mentioned needing to block Docker's update URL "to save battery." Are you suggesting that the very act of checking for updates causes undue strain on your battery and that running Little Snitch to block what I assume is a single HTTP call actually uses less battery?

@dieucao I think the current points of confusion/contention are not so much around how things work as they are around why specific options are only available to paying customers. As a free user I cannot opt out of daily reminders for a new version even if I have reviewed the changes in the new version and determined that they do not offer me anything or, worse, actually break something that I am currently working on.

As a Pro user Docker will notify me of a new version but I have the option of telling Docker that I am not interested in v3.3.1 (for example), so stop reminding me about updates until v3.3.2 is released. The question most, myself included, seem to be asking now is "why is this a Pro-only feature?"

The stated reason for the reminders is to encourage people to "do the right thing" (upgrade) but why, then, does the reminder notification include a reminder to free users that they can get rid of these notifications by upgrading to a Pro subscription? Why not just hide the "Skip this version" button entirely for free users?

Similarly, only users with a Team (or Large) subscription can completely opt out of checking for updates. Why is this feature restricted to that group? And why does the UI for the lower tiers include a greyed-out version of the checkbox with a "TEAM" tag next to it? Again, why not just hide the option completely for Pro and Free users who don't qualify for it?

I think there is probably a lot of people who consider an upgrade to their Docker environment to be a Change (with a capital "C") that should be rolled out via a Change Management process. If I'm a Developer working in an Agile team using SCRUM, that probably means that when Docker releases an update, we add a ticket to the backlog that we will then pull into a future sprint to manage upgrading our environment. Maybe the Docker team believes that the majority of people working in this type of environment are already on Pro or Team plans and therefore don't care that opting out of notifications is a paid-only feature but, based on the feedback here, I suspect that is not the case.

It is tough to not conclude that the reason for these design choices is that the Docker team wants to encourage people to either stay current or pay to use the Docker software. While I don't think there is anything wrong with this stance, I also think there is value in transparency.

[KheeWong]

There are some things money can't buy. For everything else 🎵 money money money 🎵

[Zipfer]

Just a suggestion to make everyone happy:
Why not allow do disable updates and popups - 1 button (has an update icon in tray/opened menu)
For anyone who wants old version support - the TEAM version
If someone - want to disable a particular update - the TEAM version
If someone created a bug and choose an old version - forward it to the TEAM account.
Conclusion: For anyone who wants old version support you have TEAM version, for other people who just work with their own environment and don't want any bugs after updates, interruption/notification ability to disable the distracting notifications.
Win-Win.

[stephen-turner]

It is tough to not conclude that the reason for these design choices is that the Docker team wants to encourage people to either stay current or pay to use the Docker software. While I don't think there is anything wrong with this stance, I also think there is value in transparency.

We want everyone to stay current. E.g. we don't take support tickets on old versions even from paying users. But we recognise that in a commercial environment, it's not always possible to roll changes out quickly, so we allow Pro and Team subscribers a bit more latitude.

I think there is probably a lot of people who consider an upgrade to their Docker environment to be a Change (with a capital "C") that should be rolled out via a Change Management process. If I'm a Developer working in an Agile team using SCRUM, that probably means that when Docker releases an update, we add a ticket to the backlog that we will then pull into a future sprint to manage upgrading our environment. Maybe the Docker team believes that the majority of people working in this type of environment are already on Pro or Team plans and therefore don't care that opting out of notifications is a paid-only feature but, based on the feedback here, I suspect that is not the case.

I think this is the heart of the issue. Unlike some other developer software, we haven't made Docker Desktop "free for personal use only". But if you do choose to use the community version, you can be expect to get the options more appropriate for a personal user.

[Harti]

ITT: People trying to make money complaining about people trying to make money. Give them a break!

While I will admit that "nagging" me to get on a Pro/Teams plan will reduce the likelihood of me considering a Pro/Teams plan, I'll state that it is fair business practice. Maybe it's not the solution everybody wanted in a perfect world, but it is understandable and most importantly enables us to work again. Ever used a premium IDE on trial and got prompted to upgrade? Play a free mobile game and have to click X to dismiss ads? Yeah, that's pretty much how things work.

We got what we needed: the ability to prevent the software from updating itself to sustain stability in our projects.
Who cares about you now having to create and plan tasks into sprints so your team can stay on the latest version, or that you need to make one extra click? Be happy that they don't lock the "Start Docker automatically" behind a paywall.

This is really turning into a "choosing beggars" thread and it is ridiculous how you take the Docker team's efforts for granted as a service to the public. If you don't like the new notifications, downgrade to 2.5.0.1. Please leave this thread for issues with the implementation.

[Harti]

Speaking of issues:
My IT policy prohibits running executables located within AppData. Without "...\AppData\Local\Temp<random hash>\Docker Desktop Installer.exe" starting, Docker Desktop as a whole won't start. I had hoped that version 3.3.0 will remove that .exe from being run, but it didn't.

Is there a workaround where I can just start the regular Docker Desktop software without the Installer.exe chiming in?

[stephen-turner]

There are no changes when updating to 3.3.0, only when updating from 3.3.0 to the next version, so right now you're still on the old behaviour.

However, going forward, once you've downloaded the update, you still can't stop it installing on next launch. Your choice is at download time.

[Harti]

However, going forward, once you've downloaded the update, you still can't stop it installing on next launch. Your choice is at download time.

It seems that a new "Docker Desktop Installer.exe" is being generated upon each launch of "Docker Desktop.exe", even on a "clean" install of 3.3.0 where no update should yet be available. Did I miss a registry entry or is this intentional, or did you mean that this will only no longer happen once the next update is available (and got declined)?

(Just checking what the target behavior is - I'll create a separate issue for this when it's not intentional)

Thanks!

[stephen-turner]

No, I don't think that's intentional, please create a ticket in docker/for-win. Thanks.

[cweagans]

But if you do choose to use the community version, you can be expect to get the options more appropriate for a personal user.

This is really the core issue: docker is a developer tool. There is fundamentally no difference between a developer who is using docker on a team project vs a personal project: if you're just trying to get things done (on a team or otherwise), the last thing you want is to have to deal with a docker upgrade (or any other meta-work for that matter). I want to write code and I want my tools to get out of the way when I'm not using them.

If Docker for Mac were so stable and the releases so reliable that things weren't regularly breaking with new releases, this would be a different conversation. As it is right now, I can't trust that an upgrade won't break any particular workflow, so I'll do the upgrade when I have the time/energy/inclination. If that means buying/using Little Snitch, fine. I'd rather pay money to Little Snitch than pay for the privilege of being allowed to decide that I don't want to be constantly nagged to install a docker update.

Just to be clear: I have no issue paying for software. I would even pay for Docker for Mac. I am opposed to software that makes demands of my time and attention like this though. Just doesn't work for me.

[dakimaz]

@stephen-turner
Just FYI the link you have here for downloading:
https://www.docker.com/products/docker-desktop
Still gives you version 3.2.2 and not 3.3.0
3.2.2 tried to update to 3.3.0 which failed and left my docker desktop inoperable and I had to reinstall it. Since you don't have version numbers as part of the installer file name, I didn't notice I re-downloaded 3.2.2 and not 3.3.0

Thanks for removing the force auto updates. Anytime I had to reboot my machine or restart the docker desktop app I was forced to reinstall it, since the update always failed and trashed my existing installation.

[rbluethl]

I was really looking forward to disable auto updates. This is a critical feature, since we're using Docker to operate a Kiosk system, which needs to start automatically when rebooting the machine. So Docker will still prompt to download and install an update? That's actually very disappointing. :-( Is there anything else I can do to "mute" and disable auto updates?

[toph-allen]

Yeah, this is super frustrating. In the space of a weekend, Docker's auto-update caused this bug. Eventually, wiping and re-installing it gave me this issue. I feel like auto-updates would be easier to stomach if I hadn't encountered these workflow-breaking issues in final releases.

[Pomax]

@rbluethl if you run a kiosk, firewall docker so it can't talk to public networks? That way it'll never even know there's an update. But if your kiosk is also internet-connected, then running potentially security-compromised software open to anyone to exploit rather than making sure the software that's running it is updated every week is kind of... questionable?

[rbluethl]

@Pomax I'm not debating the importance of security updates, but I'd rather perform them manually every week instead of risking the application not coming up due to an automatic update being performed. Although maybe granting the service higher privileges would be an option, so that Windows doesn't prompt for Administrator privilege.

[Pomax]

if you do them manually every week anyway, then there is no problem? As per #183 (comment), for the first two weeks, all that happens is that you get a different looking systray icon (which folks won't see because presumably your kiosk is full screen). It's not until after 2 weeks that docker will go "hey you really should update at this point" on startup.

[rbluethl]

Ah, that makes sense. I obviously missed that one - thanks for pointing out. Then there shouldn't be any problem. Might be worth mentioning somewhere more visibly. 👍

[stephen-turner]

OK, I can see that this conversation is going round in circles and people aren't able to read everything that's already been written, so I'm going to lock it permanently now and summarise one last time.

[stephen-turner]

In the latest release these are the changes. Our intent is to balance encouraging people to take updates promptly, with giving them the flexibility to defer downloading and installing until later if they need to.

• When there is a new release, you will get a notification on the whale icon.
• After two weeks, you will start getting daily popups too.
• You can download the update at that point, and it will install on next restart.
• But you are never forced to take it, you have the option to dismiss the popup until the next day.

The above is what users of the community edition see. We also recognise that commercial environments may have additional constraints around longer periods of stability, planned rollouts, or IT-managed rollouts. So for Pro and Team customers, there are additional options:

• Pro and Team customers can select "Skip this Update" to ignore all future notifications about a specific update.
• Team customers can turn off all checking for updates ever.