<aside> ➡️

You might wonder:

WIP: What is a breaking change?

</aside>

1. Don’t introduce a breaking change
2. If you don’t see a way to avoid it, consult with @Anonymous group
3. Mark your commit with ! , as per Conventional Commits.
4. Open a PR in status-desktop and status-mobile.
   1. Updating status-go in desktop: git workflow
5. PRs for both clients MUST be opened, tested and approved BEFORE merging status-go PR.

<aside> <img src="https://prod-files-secure.s3.us-west-2.amazonaws.com/1518abd9-c08f-4989-93c1-96525e62bce5/40077bee-217b-4300-9a0a-f7e6bc025216/pngegg.png" alt="https://prod-files-secure.s3.us-west-2.amazonaws.com/1518abd9-c08f-4989-93c1-96525e62bce5/40077bee-217b-4300-9a0a-f7e6bc025216/pngegg.png" width="40px" />

Getting your PR reviewed, getting people to adapt all clients to your changes, getting those PRs reviewed and QA'd will take a LONG time.

So the whole process will require a lot of patience. If that's not one of your virtues, think REALLY HARD if you need to make this breaking change.

</aside>

Tips

• Wherever possible, try to implement your changes in a way doesn't require both clients to adapt at the same time.

  • Example: You want to rework package A. Instead of making changes to it, if feasible, try to make a new package Av2, with equivalent v2 API endpoints. This way the clients can decide to keep using the old endpoints/package or jump to the new one whenever appropriate.

• Consider creating a feature flag in feature_flags.go

  For example, you can easily create a short-lived feature flag to make improvements until the solution is completely proven. Not always feasible, but could be used more often to reduce risk.

• The sequence when adding a new version of an endpoint should be:

  1. Mark old endpoint as deprecated with a comment Deprecated: <what to use instead>
  2. (Optional) Add a warning log when calling them?
  3. Notify client teams about the deprecation in a public channel
  4. Ensure there are Github issues created on each client's board to adapt to the new endpoint. Create a status-go issue blocked by the previous ones for removing deprecated code.
  5. When all clients make the jump to the new endpoint, remove the old ones and all associated code.

Rule of thumb

It’s good to think of status-go like you don’t know of status-desktop and status-mobile clients. Imagine that it’s an open-source library with a 1000 use cases. What counts as a breaking change then? And when is it reasonable to introduce one?

Automation

Put your ideas below.

1. PR checklist
2. APPROVED: Auto-adding breaking change label:
   • https://github.com/status-im/status-go/pull/5835
   • ‣
3. APPROVED: Require approval from a member of each team on EACH PR
4. APPROVED: Require approval from QA of each team on a BREAKING CHANGE