Lemmy

496 readers

1 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

nutomic@lemmy.ml

131

Lemmy v0.18.0 Release (join-lemmy.org)

submitted 1 year ago by dessalines@lemmy.ml to c/lemmy@lemmy.ml

55 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] fishcharlie@eventfrontier.com 26 points 1 year ago (1 children)

@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 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.

[–] dessalines@lemmy.ml 1 points 1 year ago

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.