4 ms·

>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

by simias 6y ago

>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. Why not just outright reject issues on outdated version of the software? Decide that you won't support versions older than x and roll with that. This way the users can consider that when they weigh the risks of updating. >For those with this pain right now: I think installing Docker Desktop 2.5.0.1 is the only solution. Well that sure backfired.

kazen44 6y ago
> Why not just outright reject issues on outdated version of the software? Decide that you won't support versions older than x and roll with that. This way the users can consider that when they weigh the risks of updating. i don' t understand why this is not something more companies do. Most operational systems (networking equipment, server equipment etc) have release cycles, in which current version -2 is the usual schedule in regards to support. Or just do it the way openBSD does it, and only support the last two releases of the software.
- eyelidlessness 6y ago
  I’m a fan of this approach (or variations with a LTS schedule). But it’s worth noting that it’s also widely criticized depending on context. For instance, Apple has a similar support schedule for its various OSes, and that draws a ton of nerd ire because it’s frequently interpreted as “planned obsolescence”.
aidenn0 6y ago
> Why not just outright reject issues on outdated version of the software? Decide that you won't support versions older than x and roll with that. This way the users can consider that when they weigh the risks of updating. In my experience the overwhelming majority of bug reports do not include the version.
- namrog84 6y ago
  Then close issue as "needs more info" until people do? Or make it a required field or highly emphasized in bug template.
  - simias 6y ago
    You could even have a bot automatically asking for the version if it's not mentioned, and closing the ticket automatically if the version is no longer supported. A bit rude, but it gets the point across...
  - eyelidlessness 6y ago
    This, plus add prominent UX in the product to file tickets, populating version (and reasonably anonymized host/environment details) by default.
p1necone 6y ago
Agreed. Whether or not you force auto updating is totally orthogonal to whether or not you support old versions of the software.
- gmfawcett 6y ago
  I don't think that's what orthogonal means. :) If I'm forcing you to upgrade, why on earth would I support older versions of the software?
  - eyelidlessness 6y ago
    Because if you look at their version adoption chart there’s a long tail between release and propagation. They’re still either supporting older versions for some time or making the arbitrary decision to ignore those users who haven’t restarted to get the new version.
    - p1necone 6y ago
      Also it's perfectly possible to say "we'll only support latest + latest LTS" without forcing auto updates.
pseigo 6y ago
> it's a mess to investigate when you have reports from 1 year old version Here's a process I've done, it may sound like a lot of work but it goes quickly if your tools are set up properly: Require versions and logs with bug reports; checkout the tag for that version; build; reproduce the issue and if it doesn't reproduce on the latest build then it might've been fixed (can ask other devs, reference changelogs and recently closed issues, git blames in that part of the codebase to lead back to PRs, etc.); then investigate. If the bug is already solved in a newer version, you can close the ticket or provide a hotfix build with the fix if it's low effort (big architectual changes are a no-go; now you have a reason why or why not to provide a fix). If the bug hasn't been solved, you can fix it for the customer and forward port that to the latest dev branch. Two birds with one stone.
- RHSeeger 6y ago
  > it goes quickly > reproduce the issue and To be fair, just reproducing an issue can sometimes take days.
kelnos 6y ago
> Why not just outright reject issues on outdated version of the software? Because that still requires time to deal with, especially if you have free-form support avenues, like a Slack channel. If someone comes in and pastes a stack trace, I still have to take time to ask them what version they are using, and tell them to try on the latest version. And no amount of bot autoresponses will ensure you don't have to get personally involved. Yeah, if it's something like GitHub Issues, you can set up an issue template that requires the version number, and a bot that checks all submissions and auto-closes if the version number is missing or not the latest. But at least for one project I work on, it's rare that someone goes to the issue tracker first before asking for help in Slack.

by simias 6y ago

kazen44 6y ago

> Why not just outright reject issues on outdated version of the software? Decide that you won't support versions older than x and roll with that. This way the users can consider that when they weigh the risks of updating. i don' t understand why this is not something more companies do. Most operational systems (networking equipment, server equipment etc) have release cycles, in which current version -2 is the usual schedule in regards to support. Or just do it the way openBSD does it, and only support the last two releases of the software.

eyelidlessness 6y ago
I’m a fan of this approach (or variations with a LTS schedule). But it’s worth noting that it’s also widely criticized depending on context. For instance, Apple has a similar support schedule for its various OSes, and that draws a ton of nerd ire because it’s frequently interpreted as “planned obsolescence”.

aidenn0 6y ago

namrog84 6y ago
Then close issue as "needs more info" until people do? Or make it a required field or highly emphasized in bug template.
- simias 6y ago
  You could even have a bot automatically asking for the version if it's not mentioned, and closing the ticket automatically if the version is no longer supported. A bit rude, but it gets the point across...
- eyelidlessness 6y ago
  This, plus add prominent UX in the product to file tickets, populating version (and reasonably anonymized host/environment details) by default.

p1necone 6y ago

Agreed. Whether or not you force auto updating is totally orthogonal to whether or not you support old versions of the software.

gmfawcett 6y ago
I don't think that's what orthogonal means. :) If I'm forcing you to upgrade, why on earth would I support older versions of the software?
- eyelidlessness 6y ago
  Because if you look at their version adoption chart there’s a long tail between release and propagation. They’re still either supporting older versions for some time or making the arbitrary decision to ignore those users who haven’t restarted to get the new version.
  - p1necone 6y ago
    Also it's perfectly possible to say "we'll only support latest + latest LTS" without forcing auto updates.

pseigo 6y ago

> it's a mess to investigate when you have reports from 1 year old version Here's a process I've done, it may sound like a lot of work but it goes quickly if your tools are set up properly: Require versions and logs with bug reports; checkout the tag for that version; build; reproduce the issue and if it doesn't reproduce on the latest build then it might've been fixed (can ask other devs, reference changelogs and recently closed issues, git blames in that part of the codebase to lead back to PRs, etc.); then investigate. If the bug is already solved in a newer version, you can close the ticket or provide a hotfix build with the fix if it's low effort (big architectual changes are a no-go; now you have a reason why or why not to provide a fix). If the bug hasn't been solved, you can fix it for the customer and forward port that to the latest dev branch. Two birds with one stone.

RHSeeger 6y ago
> it goes quickly > reproduce the issue and To be fair, just reproducing an issue can sometimes take days.

kelnos 6y ago

> Why not just outright reject issues on outdated version of the software? Because that still requires time to deal with, especially if you have free-form support avenues, like a Slack channel. If someone comes in and pastes a stack trace, I still have to take time to ask them what version they are using, and tell them to try on the latest version. And no amount of bot autoresponses will ensure you don't have to get personally involved. Yeah, if it's something like GitHub Issues, you can set up an issue template that requires the version number, and a bot that checks all submissions and auto-closes if the version number is missing or not the latest. But at least for one project I work on, it's rare that someone goes to the issue tracker first before asking for help in Slack.