Why are breaking changes increment the PATCH number of the package?

[Zaid-Ajaj]

@forki The change log clearly states that the changes are breaking:

2.5.1

• BREAKING: use NetInfo from react-native-netinfo

2.5.0

• BREAKING: Deprecating Fable.ReactNativeDeviceInfo. Please use https://github.com/martinmoec/Fable.ReactNative.DeviceInfo

2.4.1

• BREAKING: use ToolbarAndroid from @react-native-community/toolbar-android

2.3.0

• BREAKING: Put onActionSelected into properties of ToolbarAndroid

Yet there is no single update in the major version? This still ties up to #54 where now we not even considering communicating how version changes affect user code

cc @MangelMaxime @alfonsogarciacaro

[forki]

Because this never used SemVer. But we could start in to do that. Zaid Ajaj <[email protected]> schrieb am Mo., 23. März 2020, 14:19:

…

@forki <https://github.com/forki> The change log clearly states that the changes are breaking: 2.5.1 - BREAKING: use NetInfo from react-native-netinfo 2.5.0 - BREAKING: Deprecating Fable.ReactNativeDeviceInfo. Please use https://github.com/martinmoec/Fable.ReactNative.DeviceInfo 2.4.1 - BREAKING: use ToolbarAndroid from @react-native-community/toolbar-android 2.3.0 - BREAKING: Put onActionSelected into properties of ToolbarAndroid Yet there is no single update in the major version? This still ties up to #54 <#54> where now we not even considering communicating how version changes affect user code cc @MangelMaxime <https://github.com/MangelMaxime> @alfonsogarciacaro <https://github.com/alfonsogarciacaro> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#59>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOANDDNAAJS2HXYIROSLTRI5OXJANCNFSM4LR3V37Q> .

[Zaid-Ajaj]

But we could start in to do that.

Can we please try to do that for any upcoming changes 🙏 (It would also be great if you at least make a version increment in the major number to reflect what has been going on recently)

[forki]

the problem is that RN itself is not really following semver. It's huge chaos and it's hard for our lib to follow that. basically every change is breaking Am Mo., 23. März 2020 um 14:51 Uhr schrieb Zaid Ajaj < [email protected]>:

…

But we could start in to do that. Can we please try to do that for any upcoming changes 🙏 (It would also be great if you at least make a version increment in the major number to reflect what has been going on recently) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOANEVUXVANO75VHINHHLRI5SOBANCNFSM4LR3V37Q> .

[forki]

@Zaid-Ajaj in some sense I was trying to maintain some value of how breaking I think it is. In a strong SemVer sense we need to increase the major with every single release and that's also not really helpful.

[Zaid-Ajaj]

basically every change is breaking

A breaking change in the third-party library doesn't necessarily mean a breaking change in the Fable binding itself of that library. For example the change 2.5.0 -> 2.5.1 to use NetInfo from react-native-netinfo instead of importing react-native could have been non-breaking if we were using Femto and had included the npm package metadata. Then a simple upgrade would bring in the correct dependency without having to break anything from the API or introduce changes in the public API surface.

we need to increase the major with every single release and that's also not really helpful.

Communicating breaking changes is absolutely helpful. Again, the solution for this is outlined in #54 and allows for the proper management of each individual package rather than having everything in one package where (as you say) the increase in major version will not be helpful.

[forki]

> A breaking change in the third-party library doesn't necessarily mean a

breaking change in the Fable binding itself of that library For RN history shows it almost always breaking. Really. Am Mo., 23. März 2020 um 15:08 Uhr schrieb Zaid Ajaj < [email protected]>:

…

basically every change is breaking A breaking change in the third-party library doesn't necessarily mean a breaking change in the Fable binding itself of that library. For example the change 2.5.0 -> 2.5.1 to use NetInfo from react-native-netinfo instead of importing react-native could have been non-breaking if we were using Femto and had included the npm package metadata. Then a simple upgrade would bring in the correct dependency without having to break anything from the API or introduce changes in the public API surface. we need to increase the major with every single release and that's also not really helpful. Communicating breaking changes is absolutely helpful. Again, the solution for this is outlined in #54 <#54> and allows for the proper management of each individual package rather than having everything in one package where (as you say) the increase in major version will not be helpful. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOANF3PE5KGKV4X6F5HWLRI5UOTANCNFSM4LR3V37Q> .

[forki]

That said, femto would have helped to mitigate the current change. But the problem here is that in some sense the change is only a bugfix for the breaking change in RN that we did not know of before. And God knows how many more we have to do since they don't even put all of those into their own changelog. It's confusing as fuck. But I try my best to find all of those... Steffen Forkmann <[email protected]> schrieb am Mo., 23. März 2020, 15:22:

…

>> A breaking change in the third-party library doesn't necessarily mean a breaking change in the Fable binding itself of that library For RN history shows it almost always breaking. Really. Am Mo., 23. März 2020 um 15:08 Uhr schrieb Zaid Ajaj < ***@***.***>: > basically every change is breaking > > A breaking change in the third-party library doesn't necessarily mean a > breaking change in the Fable binding itself of that library. For example > the change 2.5.0 -> 2.5.1 to use NetInfo from react-native-netinfo > instead of importing react-native could have been non-breaking if we > were using Femto and had included the npm package metadata. Then a simple > upgrade would bring in the correct dependency without having to break > anything from the API or introduce changes in the public API surface. > > we need to increase the major with every single release and that's also > not really helpful. > > Communicating breaking changes is absolutely helpful. Again, the solution > for this is outlined in #54 > <#54> and > allows for the proper management of each individual package rather than > having everything in one package where (as you say) the increase in major > version will not be helpful. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#59 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAAOANF3PE5KGKV4X6F5HWLRI5UOTANCNFSM4LR3V37Q> > . >

[Zaid-Ajaj]

the problem here is that in some sense the change is only a bugfix for the
breaking change in RN that we did not know of before.

I don't want to keep beating a dead horse here. My point is that we can avoid the situation where breaking changes in RN surface as breaking changes in the binding itself because it provides a layer on top if it is only internal binding details that are changing.