@[email protected] Thanks for the information here and all the hard work you have put into this release.
Gotta say tho, as the maintainer of Lemmy-Swift-Client, breaking API changes like this without an API version bump, make API development within the community incredibly difficult.
So my question to you would be, what is the purpose of having v3 in the API path, if the true test of API compatibility is the GetServerResponse version field? And breaking changes will occur in GetServerResponse version changes as opposed to the version in the API path? That doesn’t quite make sense to me.
Would love your perspective so I can figure out how to best design the package API to accommodate client developers who might have to contend with multiple server versions.
The lemmy API still hasn’t hit a version 1.0, and should very much be considered beta, with a lot of active and breaking changes. When we do stabilize it, then we can start to make these breaking API changes more solid. The v3 should probably just go away at this point, because we have too much active development and API changes to justify it.
What we do on lemmy-js-client, which has its types auto-generated from rust, is use tags that match our lemmy release semver version.
I’m not sure how you built lemmy-swift-client ( I hope its auto-generated from either the rust or lemmy-js-client types), but you could do the same thing: use tags to version it, then applications could use those tagged versions.
Got it. That is super helpful. Really appreciate it. Sadly, I’m not doing auto-generated (yet). But it’s on my horizon for sure. I’ll work on making that a higher priority. Thanks again.
@[email protected] Thanks for the information here and all the hard work you have put into this release.
Gotta say tho, as the maintainer of Lemmy-Swift-Client, breaking API changes like this without an API version bump, make API development within the community incredibly difficult.
So my question to you would be, what is the purpose of having
v3in the API path, if the true test of API compatibility is the GetServerResponseversionfield? And breaking changes will occur in GetServerResponseversionchanges as opposed to the version in the API path? That doesn’t quite make sense to me.Would love your perspective so I can figure out how to best design the package API to accommodate client developers who might have to contend with multiple server versions.
The lemmy API still hasn’t hit a version 1.0, and should very much be considered beta, with a lot of active and breaking changes. When we do stabilize it, then we can start to make these breaking API changes more solid. The
v3should probably just go away at this point, because we have too much active development and API changes to justify it.What we do on lemmy-js-client, which has its types auto-generated from rust, is use tags that match our lemmy release semver version.
I’m not sure how you built lemmy-swift-client ( I hope its auto-generated from either the rust or lemmy-js-client types), but you could do the same thing: use tags to version it, then applications could use those tagged versions.
Got it. That is super helpful. Really appreciate it. Sadly, I’m not doing auto-generated (yet). But it’s on my horizon for sure. I’ll work on making that a higher priority. Thanks again.