142
Lemmy v0.18.0 Release
(join-lemmy.org)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 23 Jun 2023
142 points (98.0% liked)
Lemmy
12443 readers
80 users here now
Everything about Lemmy; bugs, gripes, praises, and advocacy.
For discussion about the lemmy.ml instance, go to !meta@lemmy.ml.
founded 4 years ago
MODERATORS
@dessalines@lemmy.ml 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.