User expectations are different for mobile apps -- anecdotally it seems users not as annoyed by mobile app updates as they would be for Flash or even Word, because the process is a lot lighter and less painful. For web applications it's transparent to the end user.

But, yes for rich client apps it's a concern. I think the trick is to deliver features rather than bug fixes and shape user expectations towards getting something new from an update rather than getting nothing but fixes that should have been in place to begin with.

If users have automatic/background updates, sure, they apparently don't care about release notes. For everyone else, the release notes are really the only way to know what changes are going to happen upon clicking "Update". Having those notes be [effectively] blank is a substantial disservice to the user.

It's depressingly frequent that an app I used to enjoy takes a major dive in user experience. For a contrived example, I don't like finding out I am now suddenly blocked from using my messaging app because they force me to use a new cloud-based account system I can't opt out of, and none of this was mentioned before I clicked Update. Or another favorite: an update that does nothing more than introduce in-app advertisements.

Are you saying because a new version breaks the current build of a downstream proprietary application, that should constitute a high priority support request from the maintainers of the project?

That doesn't compute with me. If they were paying for forwards-compatibility and had that expectation in a contract, sure. But they should be able to make changes they see fit without having to make trade-offs to ensure future compatibility with an Enterprise organisation's product.

At that point they're basically making design decisions to suit the Enterprise, at which case - you're not just free resources for software engineering for the organisation, you're actively pushing your project to be vendor-compatible. I could see this reasoning if your project is largely funded by them (Chromium), but in this case, they're not.

Users are missing security fixes, developers can't use new features in new versions.

For example, you're right that a notification on our homepage, in addition to our docs, would have been a good reminder to users. We'll work on getting a blog post and better documentation up that explains exactly how to access data from before 11/11. We really appreciate the candid feedback here.

We're a very fast growing startup tackling a herculean task, so we're bound to make mistakes and this is one of them — I hope you can understand. We want to be much better communicators going forward.

As far as users are concerned, random stuff changing for reasons unrelated to their actions are all the same.

The ability to turn that crap off is entirely why I'd want a different client.

And it's not really like you can have your feature available everywhere on day 1 really, even on a proprietary client. People often lag behind updating their apps on their devices.

I managed a fleet of 60k mobiles of which 40k byod (personally owned). and we often ran into issues with people not updating even included apps like chrome for years and we'd have to email them and even ban them when a serious vulnerability was found in the wild.

If you have a feature that is used by one customer out of thousands but it's causing problems at every update you push out. It might be better to remove the feature and fire the customer, than to keep supporting it no matter what.

> As others have mentioned, requiring updates to run correctly is actually a fault of the underlying system, and the change therein.

Theoretically yes, but this changed from the customer perspective as well. Whereas a few years ago, it was a sign of quality software that no updates were required, it's now a sign of an app that is unmaintained. No updates is a negative signal and thus, updates are mandatory to be perceived as high quality software and to a certain extend, to prevent 1-star reviews.

> If there is a need, the need will be met, eventually, by someone, and if it is truly a "need", people will be willing to pay money for it.

"If there is a need, the need will be met, eventually." Period. The rest of the sentence isn't always true. People aren't necessarily willing to pay money for it and there are other revenue streams ("pay with your data").

I absolutely believe that the "you're welcome to try" part of that is important, assuming there's no known issue (which there may sometimes be). Developers also have an upper bound on available support bandwidth. I don't think apps (or websites) should prevent users from even trying, unless there's some specific technical reason (e.g. a known incompatibility that's producing substantial support burden just to triage, or a library or API that simply doesn't exist on the older version). I do think it's reasonable to say "please upgrade and try again, and if you're still experiencing the issue we'll take a look".

Along the same lines, if a user reports an issue to a website where it doesn't function properly in Chrome 12, or Firefox 9, it's entirely reasonable for the site to respond with "please upgrade, we don't support outdated browsers". It's a little more questionable for a site to say that about a version released the previous month, unless the site is a tech demo for bleeding-edge technology. But at no point do I think a site should actually block users attempting to use older browsers; at most, it's reasonable to show a "not supported or tested, might not work" message.

Eg tab groups were pushed onto mobile users in Chrome, yet it feels like the people who made the UI change don't actually use mobile chrome much, because the UX is awful. Luckily you can trudge through flags to change this behavior to the old one, but how long until we can't do that anymore?

I really don't get the wailing and gnashing of teeth against even the principle of adding update checking and error reporting features. Real, regular people will get tangible benefits from these features. Their scope is so limited and implementation (now) drawn down to such a sharp point I can't really sympathize with a hard-line counterposition that these features must be defacto evil.

Mandatory updates should only happen for critical security issues and even those don't need to be fixed on a five minute interval, once a day at most for a check and less frequently is probably fine as well unless the app is absolutely mission critical and people will die. And even then you should probably wonder if your QA is so bad that you need to be able to intervene on a moments notice, better to design your process in such a way that you can alert the user rather than to forcibly upgrade their system, especially if there is a chance that you'll get it wrong (again).

An upgrade is always a burden on the users, so you really don't want to do this too often and even if you are capable of releasing multiple updates per week it would be ridiculous to expect your users to follow that frequency.