Update The upgrade was done, DB migrations took around 5 minutes. We’ll keep an eye out for (new) issues but for now it seems to be OK.

Original message We will upgrade lemmy.world to 0.18.3 today at 20:00 UTC+2 (Check what this isn in your timezone). Expect the site to be down for a few minutes. ““Edit”” I was warned it could be more than a few minutes. The database update might even take 30 minutes or longer.

Release notes for 0.18.3 can be found here: https://github.com/LemmyNet/lemmy/blob/main/RELEASES.md

(This is unrelated to the downtimes we experienced lately, those are caused by attacks that we’re still looking into mitigating. Sorry for those)

  • quaddo@reddthat.com
    link
    fedilink
    English
    arrow-up
    23
    arrow-down
    1
    ·
    1 year ago

    Fwiw, it can be helpful to call out the date for such changes. Preferably in YYYY-MM-DD (ISO 8601).

    While it’s helpful to link to an off-site timezone converter tool (thanks for that, btw), “today” can be a different date, depending on where in the world you are. For example, Japan, Australia, and New Zealand.

        • quaddo@reddthat.com
          link
          fedilink
          English
          arrow-up
          3
          ·
          1 year ago

          As someone who has had to grind through heaps of logs over the years, from systems in various timezones, from products that disagreed on the ‘best’ datetime format, I’ve become a fan of adopting ISO 8601 as much as possible. For personal systems such as a laptop, that’s a different story. But if I’m spinning up an EC2 instance in us-west-2 or a VM in Central Europe, I avoid the whole “err, what TZ is this in, or should even be in?” decision-making process and just run with WHO CARES IT’S SET TO UTC NOW LET’S MOVE ON ALREADY 😀

          And not that anyone here is likely to care, but here’s a quick shout out to lnav - The Logfile Navigator for grinding on system logs (for systems where something like Prometheus or whatever hasn’t been proactively set up).