Here is our regular update that explains what we have been working on for the past two weeks. This should allow average users to keep up with development, without reading Github comments or knowing how to program.

We are slowly getting closer to the 0.19 release, although there is still a lot of work left. Client developers should read this post with information about breaking changes to update their projects.

Edit: You can test the latest 0.19 code on voyager.lemmy.ml, or by installing 0.19.0-beta.8 on your server. Be sure to report any bugs on Github.

@nutomic has closed over 100 issues, most of them duplicates, invalid or already resolved ones. He also made numerous pull requests to fix minor bugs and implement small enhancements. This includes a bug fix for federation of admin actions which was released as 0.18.5. He is also changing the way HTML escaping is handled to avoid broken texts.

@dessalines is working on redesigning the join-lemmy.org website, adding the apps and instances pages. Also worked on rewriting the Docker images to use Debian as base instead of Alpine. Additionally he is adding support for new backend features to lemmy-ui (scaled search and cursor-based pagination).

@SleeplessOne1917 has implemented support for new block instance feature, finished implementing the remote follow feature, and updated 2-Factor-Auth to account for a backend rework. He also implemented some bug fixes. He has also been working on adding authentication to lemmy-ui-leptos.

Support development

@dessalines and @nutomic are working full-time on Lemmy to integrate community contributions, fix bugs, optimize performance and much more. This work is funded exclusively through donations.

If you like using Lemmy, and want to make sure that we will always be available to work full time building it, consider donating to support its development. Recurring donations are ideal because they allow for long-term planning. But also one-time donations of any amount help us.

  • chiisana@lemmy.chiisana.net
    link
    fedilink
    English
    arrow-up
    8
    ·
    1 year ago

    With the authentication header update, isn’t usual best practice to support both on the server side simultaneously, and set a deprecation window such that clients can update over time?

    • nutomicOPMA
      link
      fedilink
      English
      arrow-up
      9
      ·
      1 year ago

      In this case it would be too complicated to keep supporting the old auth format. Plus we want clients to update soon because sending auth parameters in the url is not secure. Anyway clients can support 0.18 and 0.19 at the same time by sending both old and new auth params at the same time.

      • chiisana@lemmy.chiisana.net
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        5
        ·
        1 year ago

        “Too complicated” feels like a cop out… there’s no question as to whether or not clients can send both, from best practice point of view, the party instilling the change should bore the burden of supporting both for some time. I cannot and do not want to change the current release train, but I hope you can take this into consideration into the future, for future breaking changes.

    • poVoq@slrpnk.net
      link
      fedilink
      English
      arrow-up
      7
      ·
      edit-2
      1 year ago

      Apparently that is mostly possible client side. Photon already supports both, and Voyager with the latest release, but with some caveats.

      • chiisana@lemmy.chiisana.net
        link
        fedilink
        English
        arrow-up
        3
        ·
        1 year ago

        I’m not asking about whether or not clients can do it, there’s no doubt a dual outbound header method is possible, but rather more about general development best practices. When instilling a change, isn’t it usually best to support both states to ensure least amount of users are immediately affected, and gradually bleed those stragglers out?