SDK Breaking Changes

I'm looking for where breaking changes are documented between SDK versions because I'm planning to update the following:

Web SDK 11.0.0 to version 13.0.0
Node SDK 9.0.0 to version 11.0.0

Since these are major updates, I'd like to make sure I address any breaking changes that come with it, if any.

https://github.com/appwrite/sdk-for-web/releases
you can check all the breaking changers for web here

Thank you! Is this applicable to both appwrite and node-appwrite?

most of the times its same. but you should check for node-appwrite here(https://github.com/appwrite/sdk-for-node/releases)

Thank you! Bookmarking these now.

I was looking at the breaking changes for createMembership() and it's fine that url is now optional but it's frustrating to keep having to check for the order of the parameters. For instance, on version 9.0.0, the order is createMembership(teamId, roles, url, email, ...) but on version 11.0.0 the order of parameters got switched all over: createMembership(teamId, roles, email, userId, phone, url, ...). Also, now I have to supply a bunch of undefined parameters just to get to the url towards the very end.

I didn't get any indication that something was wrong because Typescript just validates the types and email, userId, and url are all a bunch of string | undefined types so switching them around doesn't trigger any warnings from Typescript. Why couldn't the parameters just be made into an object? Something like:

type CreateMembershipProps = {
  teamId: string;
  roles: string[];
  email: string | undefined;
  userId: string | undefined;
  phone: string | undefined;
  url: string | undefined;
  ...
}

That way, developers can supply the parameters in any order and it wouldn't break anything and won't have to deal with parameter order gymnastics. I believe Appwrite is written in PHP but I'm sure something like this is also possible.

That's a valid thing I could say. The sdks are generated using the sdk-generator. They use the swagger spec to generate the sdk for all the languages.

If you are open up for contribution, you can make a PR in this repo, or a issue would be great so the maintainers could keep a track on it😄

I believe you the core team would have thought of this but decided against it to have similar syntax across the SDKs.

taggin @Steven here for more inputs.

Thank you. I think I'll just open an issue since I haven't done PHP in a very long time and I'm probably very rusty at this point. I think implementing the props this way is a good thing. But I do understand that there's a need to keep the SDKs consistent across implementations.

FYI - here's the issue I opened: https://github.com/appwrite/sdk-for-node/issues/62