> No, mobile scrolling wasn't "broken" for them, scrolling via their "timeline" feature was broken.
So, mobile scrolling is broken, but not all the time. Is that really the distinction you want to make right now? For the individual who said "[c]omplaints from my users are starting to come in", is that an adequate response?
> Luckily Discourse will email you when there is an update with a link to the admin page that lets you one-click upgrde the Discourse install on your server from the web UI.
Please do tell that to the parishioner whose son set up the website a year ago before he left to go to college. We all agree that software upgrades are important for security, but that doesn't justify imposing an additional artificial upgrade burden due to a backwards-incompatible breakage to the web.
The timeline feature is the sidebar that shows you where in time since the first post you are looking at. When you drag along it, it can move you to that date and time. It's a cool features but not integral to the application.
Scrolling still worked... 100% of the time on 100% of devices.
And as for the upgrade, if the parishioner can't click [0] in the web UI (a link to which was emailed to them), then I'm not sure how they are using discourse at all. And IMO they have no business hosting anything themselves as it will most likely turn into a DDoS bot within a year.
But again, there is no need to do this as the forum software worked completely fine for it's core functionality and only scrolling via the timeline was broken.
You're showing a pretty serious case of cognitive dissonance here. What previously was a theoretical problem was actualized with a real world example with actual affected users, and you've shifted to an entirely subjective argument that the breakage is "not integral to the application".
You also chose to rationalize the breakage by shifting the blame to the victim -- they have "no business hosting anything themselves". Well, great, but that isn't going to stop them. Maybe they want to ensure their web forum isn't censored by a hosting provider. It turns out that people still host their own websites in 2017, and until they all shift to centralized monolithic providers these bugs will persist for years, and you will persist in rationalizing the breakages as "flu shots".
Reread my first comment. I pointed out that the breakage would be limited in scope. Very very few applications were broken by this (broken being defined as having it's core functionality unusable).
And you seem to be completely ignoring the fact that the upgrade "path" is one click of a button. Whether you agree with my stance on the responsibility of hosting your own internet connected server or not, it's a one click button upgrade, to a fix which was made 24 hours after the problem appeared.
If your problem is a minor UI breakage of a side feature of a well maintained web application that doesn't get updated because the admin doesn't know how to click a button in response to a fix which significantly improved scrolling performance for all chrome users, how do you justify any changes at all? Call it rationalizing if you want, I'm saying it's worth the extremely small amount of pain for the bettering of all chrome users.
How can you change anything at all if that is your threshold for unacceptable? How can you even update a single line of code if you feel that such a small amount of breakage is not allowed?
Against my better judgement I did a reverse image search and found the post that you found that screenshot from [1]. The post is full of people having exactly the sort of problems you would expect from an automatic software updater, along with instructions from Jeff on how to manually update using SSH and git.
These things happen. The world is messy, and whether due to technical inadequacy or run-of-the-mill software updater bugs, web backends will not always be updated. As you've noted, this could eventually lead to security problems, and I agree -- but that doesn't justify intentionally breaking their code. To say that their breakage is justifiable because they'll be 0wned at some point anyway is an absurdly darwinian argument.
To address your last question, the way you update a system like the web is exactly the way we always have -- accretion. With very few exceptions, websites from the early 90s still work today. We didn't remove the `table` tag when we introduced flex boxes. We add new APIs while preserving existing functionality. If you want to see a fantastic talk on this exact subject, watch "Stewardship: The Sobering Parts" by Brian Goetz [2]. It is well worth your time.
And I agree that we shouldn't break things lightly, but in this case that wasn't possible.
The options were let website scrolling be laggy and janky on mobile, or break a very small amount of websites. (and your point is that things may never be updated, so no amount of "giving them the ability to opt-in to these improvements would ever help)
And I stand by my thought that they made the right decision here, despite the very few easily upgraded sites that were impacted.
So, mobile scrolling is broken, but not all the time. Is that really the distinction you want to make right now? For the individual who said "[c]omplaints from my users are starting to come in", is that an adequate response?
> Luckily Discourse will email you when there is an update with a link to the admin page that lets you one-click upgrde the Discourse install on your server from the web UI.
Please do tell that to the parishioner whose son set up the website a year ago before he left to go to college. We all agree that software upgrades are important for security, but that doesn't justify imposing an additional artificial upgrade burden due to a backwards-incompatible breakage to the web.