How can we make clear what the public API of fastlane is?

[lacostej]

Question: do we consider any public method of any class part of fastlane part of fastlane's public API?

Sometimes we receive PRs that modify public methods in fastlane in such a way that it would make those methods incompatible with existing code. Those PRs tend to fix the internal code but it's not enough as it doesn't take into account external code.

Many parts of fastlane are used programmatically by users, e.g. spaceship or even fastlane_core modules are built upon in actions or in Fastfiles directly by our users.

[rogerluan]

This is a good discussion topic! While I don't have any strong opinions about this and don't know what's a "best practice", I can think of a few options:

1. We could solve this issue is by considering (and informing users) that anything that is not a tool or an action is subject to breaking changes (this would include e.g. spaceship, fastlane_core, or any other internal components). Another way would be to add a few exceptions to the list (e.g. spaceship), and consider all the rest subject to breaking changes.

2. We could alternatively make everything that is not intended for public use private, but that would result in the same problem: when would we make this switch? It would essentially mean 1 massive breaking change for everyone, and one that users can't workaround with a simple syntax change then, which is significantly worse IMO (things like this is what motivates hard forks 😞)

3. Another way to solve this would be to simply consider that everything is public and used and that we don't wanna break anything. While this sounds good from a user perspective, it sucks for contributors, especially core ones, since they'll have to keep creating and maintaining nearly-similar duplicate methods just to support the old and new syntax of the public-facing methods that needed to be changed.

4. Major bump on every breaking change? e.g. fastlane v2.x.y to fastlane v3.0.0… This would be the theoretical by-the-book "best way", but this would probably mean we'd be release 10+ major bumps per year, not sure if that'd be cool? 😅 what ends up happening is that users are then less inclined to do the major update (even if they're not affected by the breaking changes, it's almost an irrational fear), then they'll gradually be farther and farther away from the latest and greatest changes we'll be introducing.

Happy to hear other thoughts and strategies on how to solve this. I think at the end of the day it's going to be a tough decision that we'll have to make as a community