[📚] Supported RN Versions

[wjaykim]

Documentation Feedback

Maybe we need to mention about supported rn versions.
Backward compatibility is surely important and improves developer experiences, but it makes hard to maintain for library developers.

Why don't we drop support officially for unsupported previous versions by React Native team?

By specifying the supported versions, we can set clearer goals for the versions we need to support and reduce confusion for developers using our library.

[dylancom]

Good call. I also think we shouldn't waste too much time trying to make it work with older versions, which harms progress.

[mikehardy]

Agreed - I think "current + 2 older versions" is a reasonable stance. People can keep using old versions of this module as they need, but we don't have to work to support them.

I'm not sure about the maintenance impact of including codegen artifacts for support either honestly. It may be the "best" way, but it also might be that for this specific native ads change we re-issue it as breaking, say it's react-native 0.76+ only, and not commit generated artifacts.

What I'm not sure about is the tradeoff between needing to commit new artifacts for each new react-native version (is that something we'll have to do? an unknown we can answer at least) vs how often it'll break on new versions (an unknownable unknown)

[dylancom]

I vote that we re-issue the native ads release as breaking. I would have thought before that it required little change to support 0.75.

[mikehardy]

@dylancom I'm also +1 on releasing as breaking, just make a commit with a ! in the subject and a BREAKING CHANGES message - there should be examples in the git log I think?

Probably a good idea to then re-issue something on a new branch on the current major version that has a revert of the native ads as a fix release so that it isn't lingering around as an incorrectly-breaking version...