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…
Their justification is that pre v1.0, you can break whatever you want whenever you want.
They are not wrong. If you are developing an application against a backend that clearly states “we are following semver. This version is not 1.0, therefore no API is guaranteed to be stable”, and you go on to write a client for it anyway, you don’t get to complain later when they make breaking changes.
Alternatively, you can just stop relying on their ad-hoc APIs and push for them to implement Lemmy with focus on the ActivityPub API. That is already an standard and if you come up to them with issues against their AP implementation, they will be a lot more likely to listen to you.
I’m just a scripting monkey for a systems engineering/admin team, but I have one system integration that is being fireman carried by a ton of my code. I’ve since learned that there are entire consulting companies built off selling a slightly expanded version of what I’ve one man army’d together. Maybe I overestimate my skill, but I feel qualified to talk about large projects and long term sustainability.
I’m convinced that people who talk about things like backwards compatibility as if it’s super difficult just aren’t willing to try. I won’t say shit like that is super easy, but it’s not black magic.
I think there’s a lot of programmers out there more interested in building shit than ensuring any sort of quality, that it’ll be maintainable longer than the next code review, or in thinking about any downstream effects of their code beyond the limited scope they’re developing in. Stuff like backwards compat is largely just another design pattern in a sea of them that you learn through experience. But you have to try it to learn what works and what doesn’t. Go try folks.
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.
They are not wrong. If you are developing an application against a backend that clearly states “we are following semver. This version is not 1.0, therefore no API is guaranteed to be stable”, and you go on to write a client for it anyway, you don’t get to complain later when they make breaking changes.
Alternatively, you can just stop relying on their ad-hoc APIs and push for them to implement Lemmy with focus on the ActivityPub API. That is already an standard and if you come up to them with issues against their AP implementation, they will be a lot more likely to listen to you.
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.
I’m just a scripting monkey for a systems engineering/admin team, but I have one system integration that is being fireman carried by a ton of my code. I’ve since learned that there are entire consulting companies built off selling a slightly expanded version of what I’ve one man army’d together. Maybe I overestimate my skill, but I feel qualified to talk about large projects and long term sustainability.
I’m convinced that people who talk about things like backwards compatibility as if it’s super difficult just aren’t willing to try. I won’t say shit like that is super easy, but it’s not black magic.
I think there’s a lot of programmers out there more interested in building shit than ensuring any sort of quality, that it’ll be maintainable longer than the next code review, or in thinking about any downstream effects of their code beyond the limited scope they’re developing in. Stuff like backwards compat is largely just another design pattern in a sea of them that you learn through experience. But you have to try it to learn what works and what doesn’t. Go try folks.