Some years ago we used to post weekly development updates to let the community know what we are working on. For some reason we stopped posting these updates, but now we want to continue giving you information every two weeks about the recent development progress. This should allow average users to keep up with development, without reading Github comments or knowing how to program.
We’ve been working towards a v0.19.0 release of Lemmy, which will include several breaking API changes. Once this is ready, we’ll post the these changes in dev spaces, and give app developers several weeks to support the new changes.
This week @nutomic finished implementing the block instance feature for users. It allows users to block entire instances, so that all communities from those instances will be hidden on the frontpage. Posts or comments from users of blocked instances in other communities are unaffected. He also reworked the 2-Factor-Authentication implementation, with a two-step process to enable 2FA which prevents locking yourself out. Additionally he is reworking the API authentication to be more ergonomic by using headers and cookies. Finally he is adding a feature for users to import/export community follows, bocklists and profile settings.
@dessalines is currently implementing a redesign of the join-lemmy.org website. He is also keeping the lemmy-js-client updated with the latest backend changes 1 2 3.
@phiresky optimized the way pagination is implemented. He is also fixing problems with federation workers which are causing test failures and performance problems in the development branch. These problems were introduced during a complex rewrite of the federation queue which was recently finished, and is thought to allow Lemmy federation to scale to the size of Reddit.
@SleeplessOne1917 is implementing remote follow functionality, which makes it easy to follow communities from your home instance while browsing other instances. He is also fixing problems with the way deleted and removed comments are handled .
@codyro and @ticoombs have been making improvements to lemmy-ansible, including externalizing the pict-rs configuration, adding support for AlmaLinux/RHEL, cleaning up the configuration, as well as versioning the deploys. These will make deploying and installing Lemmy much easier.
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.
- Liberapay (preferred option)
- Open Collective
- Patreon
- Cryptocurrency (scroll to bottom of page)
If these are API-breaking changes, shouldn’t you bump the major version? https://semver.org/
I think you’re forgetting this:
https://0ver.org/
Ha. Well yea, devs need to learn to commit at some point I guess.
I feel their pain lol, which is why I’m also super-hesitant to pull the trigger on
1.0.0for lemmy.We’re still hobby software created mostly by a few devs, yet people expect us to have the same stability and resources as multi-million-dollar corporations with hundreds of employees.
Oh for sure … for me, you go ahead and break backwards compatibility all you need to. Though there might be a weird phase coming up where a number of people are using apps whose development has slowed or stalled and so won’t be able to get updated.
Otherwise, my comment about “committing” was targeted at some of the notable zeroVer projects: react native, threejs, hugo and neoVim.
Fair enough.
From an end user perspective, it feels like it’s operationally stable, though I don’t know about developmentally stable. Maybe it’s worth a 1.0 release soon. Lots of people are running it in production now.
Before 1.0 we definitely need to do an API cleanup, the paths are a real mess. However that will require lots of breaking changes so Im not sure when we can do it.
see also: perpetual beta
Yea. I feel like once it can scale pretty well and has been for a bit of time that would be a good opportunity to release 1.0. But another major factor here is that the backing and sustainability of the project is still up in the air, so the flexibility of breaking changes is maybe rather valuable for a while.
We’re reserving 1.0.0 for a mostly unchanging and stable API. That def isn’t the case currently, as we’ve been rapidly adding features, changing api objects, etc. So minor versions (and usually not patch unless it’s security related), signify breaking api or config changes.