The fact that they had to hold the maintainers hands through this is disappointing. "it's a feature request not a bug" shows Stephen did not even understand the problem he introduced. Either that, or he didn't read all the comments before him.
The fact that they had to hold the maintainers hands through this is disappointing. "it's a feature request not a bug" shows Stephen did not even understand the problem he introduced. Either that, or he didn't read all the comments before him.
He clarifies a little bit further down the thread:
> It's not a bug because it's working exactly as designed. We're very aware that you regard it as a misdesign.
If a project / community has adopted specific definitions for given words such as "bug", "feature request", etc., then IMO you should not get mad at people for using them as defined.
You may feel strongly that the auto-updating feature is a terrible idea in application, and you may even disagree with this project's decision to define a "bug" as "something that isn't working as designed", and that's fine. But I don't think it suggests that Stephen does not understand the issue, or did not read the thread.
And also, who says that mis-designed features aren't bugs? In this case, they designed a bug, and shipped it.
Autoupgrading might totally be a misfeature for your usecase, but it's how this program works. If you don't want it to do that, then uninstall it.
It benefits everyone if we improve software. It benefits nobody if everyone never reports their problems and simply quietly disappears and quit their job when something in the software they use needs to be fixed -- and I think it's pretty obvious that course of action is unreasonable and unworkable.
If you don't like the way that convenience is provided to you, then yes, you don't need to use it, and that is not tantamount to telling you to give up and go move to Canada.
The developers have chosen to implement autoupdating.
That meant that in December they pushed a version which had a bug in it, and users received the bugged version. Then they pushed a version with a fix, and users received the version with the fix.
That doesn't seem worth throwing a tantrum over.
- Docker for Mac has no alternative.
- Docker for Mac periodically ships bugs that make the program (and Docker itself) unusable.
- Devs cannot downgrade -- so their workday can be productive and not wasted on fighting with the tool.
You seem to be implying that people are entitled. I suppose technically this can be true but Docker for Mac is viewed as a critical infrastructure and thus people should have venues to make it workable even if the latest version is bugged. They ask for choice and are against force automatic updating to the latest version.
> That doesn't seem worth throwing a tantrum over.
Such emotional reactions cast a doubt on whether you are arguing in good faith.
This broke production environments. That is a bug.
Bugs can introduce new development to meet acceptance criteria, if that is the right way to solve the bug.
Edit: kelnos accurately pointed out that I should have said development environment, and not production.
This broke development environments. I really hope no one is using Docker Desktop running on Mac in production.
Not to trivialize the issue; lost productivity due to a a bug in a software update sucks. But people are not getting irate customer phone calls or losing revenue because of product downtime due to this.
It could be an indirect cause of irate calls because there’s a bug in production but the dev environment is broken by Docker’s auto-update so the devs can’t work on a fix for the production bug.
If it breaks even just my desktop working environment, and that impairs my ability to remediate a production problem, it's causing production downtime. Dev environments aren't decorative.
Presumably it also would flawlessly autodeploy the fix for that bug when it gets released.
So, there was a bug. A UX bug. Bugs aren’t software-exclusive.
I may be misunderstanding your point.
I think auto-upgrades of Docker are totally fine if it makes the lives of Docker devs easier and they can concentrate on more meaningful things. After all, the majority of the user base is not paying a single cent for the software. If a paying customer complains about auto-upgrades and wants to buy into their own support branch, that's a different story.
I've no idea if Docker's auto-upgrades also include minor an major versions, though.
What's the point of having versions if you can't install them?
Or how it doesn't work, in this case.
> If you don't want it to do that, then uninstall it
And use what? There are no alternatives. Should I quit my job while I'm at it? Maybe I can just downgrade it .... oh wait ..
Hell, a huge chunk of dev work is rethinking design decisions that are misguided/under specified/break things because you only see these issues once you start having to implement details.
someone else said "this is how you get forked" and they are right for foss things, but docker isnt so trickier
It would be reasonable for people to build better tooling around rkt, or jump on the podman bandwagon
On a side note, I see plenty of developers click the "Remind Me Later" button over and over and over on the update dialog for their dev tools (and even OS). As a pathological example, I noticed one of my coworkers running a 3-year-old version of IntelliJ IDEA recently when he shared his screen on a Zoom call. But people who don't even install patch updates for months is common as well.
Docker Desktop is produced by a for-profit company, and while it is free of charge itself, it is a key customer-facing part of an ecosystem Docker monetizes by selling subscriptions to services which it leverages. It's not some solo developer’s spare time project, and if Docker wants to be a viable business, it won't be treated like one.
It's not like the developers of some OS-es didn't work hard for users to have this attitude. Nowadays you better wait at least a few days before you give in and agree to update your system, it's just a sane approach to risk control.
Sure, underlying components are open source, but I've seen no other effort to glue them together in a cohesive, single-purpose package like Docker Desktop.
Keeping people on the latest version of your software has very clear benefits to both you and your users. Unfortunately, as we see here, it can also have downsides. Ultimately it's up to the developer to decide what trade off works best for them. Input from users is important, but it's not the users' decision.
I've had the position of saying that something desired will not be done with the only thing I could honestly say without airing private disagreements being "reasons", as the person I was talking to knew I also didn't think it made sense.
Deflecting with vague statements has also been a tactic I have used, hoping that they would not persist.
That's what all of us who have ever had to go out and work around annoying decisions want you to realize.
If these people are paying for Docker Desktop, then, sure, maybe they're entitled to upgrades and support on their terms. But if they're not, I'm completely sympathetic toward developers trying to reduce their (unpaid) support burden.
Yes, this might turn people off and hinder adoption, but that's their choice to make.
EDIT: But seeing this in Docker doesn't surprise me at all. It's this kind of project that knows better than you. Compare this with general purpose tools such as SSH, Git, gcc. There's nothing special about projects like Docker and Snap and they will get eventually replaced by projects that expose more knobs to fit (private) use cases of other users.