Were there any updates on this? Did anyone end up forking it?
Not sure to be honest, @MrKaplan@lemmy.world ?
https://lemmy.world/comment/16818450
if you’re talking about the image issue from this post, I have no plans to work on that as we don’t use the image proxy but if anyone wants to PR that they’re more than welcome to do so.
I meant in general, is there anyone maintaining it and keeping it compatible with newer versions of Lemmy?
that’s answered in the comment i linked
I have some interest in trying to take that on if it’s really unmaintained now. I use mlmym and want to make sure we continue to have an interface that works w/o JS. I have relevant web programming experience, but not with Go specifically.
@nnrx@lemmy.world FYI, if you’re still here.
That would be great!
I’ve started changing some smaller things over on Fedihosting-Foundation-Forks/mlmym. I don’t really have time, motivation or Go knowledge to fully maintain and develop new functionality there, especially as I don’t use it myself, but I’m currently planning to keep it on life support at least and see if I can at least fix some stability issues.
I also already forked and updated go-lemmy, which should now support the latest Lemmy 0.19.11 APIs.
Currently the primary focus for this is to have builds for old.lemmy.world, but I wouldn’t be opposed to have this used as a generic repo if other people want to contribute. I’m currently not planning to intentionally break things in a way that would prevent usage outside of Lemmy.World, but unless there are other people interested in contributing as well, I will primarily just focus on ensuring compatibility with the Lemmy version we are running.
Maybe petition the Lemmy devs to not pointlessly break API v3 since they’re moving to v4?
Isn’t the whole point of having different api versions to not break compatibility, so apps can continue using v3?
Yep, and that’s how we do API versioning at work. One app is on like API v9 now, and I think we support back to v5 or maybe even v4.
Their justification is that pre v1.0, you can break whatever you want whenever you want. But when you’ve got a large community of people developing for the ecosystem over several years, it’s kind of a slap in the face to keep breaking the API. I appreciate that 0.19.0 - 0.19.11 has been fairly stable, but breaking v3 while also rolling out v4 is just inexcusable.
I get that v3 will eventually need to be deprecated and apps move to v4, but you’d think they’d put all their breaking changes in v4, let v4 stabilize and run concurrently with v3, and then drop v3 a few versions down the line. Except a few paid apps, I don’t think most of us are doing this full time and have other things to deal with.
But what do I know? It’s not like I do this for a living. Oh, wait…
In a comment one of the main devs mentioned worst case scenario that they could be supporting 0.19 for a long time so they’re trying not to rush 1.0.
It’s open source. If somebody wants to fix v3, they could submit patches.
It’s unfortunate that v3 is stalling but nobody is paying the devs so they can prioritize however they see fit.
I also think that right now developing missing features is more important than old APIs.
Features can be developed independently of the API and/or added without introducing breaking changes.
