search

fable-compiler / fable-react-native

Fable bindings and helpers for React Native projects
Apache License 2.0
49 stars 11 forks source link

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

Open Zaid-Ajaj opened 4 years ago

Zaid-Ajaj commented 4 years ago

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

2.5.1

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 commented 4 years ago

Because this never used SemVer.

But we could start in to do that.

Zaid Ajaj notifications@github.com 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

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 https://github.com/fable-compiler/fable-react-native/issues/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 https://github.com/fable-compiler/fable-react-native/issues/59, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAOANDDNAAJS2HXYIROSLTRI5OXJANCNFSM4LR3V37Q .

Zaid-Ajaj commented 4 years ago

But we could start in to do that.

Can we please try to do that for any upcoming changes :pray: (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 commented 4 years ago

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 < notifications@github.com>:

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 https://github.com/fable-compiler/fable-react-native/issues/59#issuecomment-602602011, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAOANEVUXVANO75VHINHHLRI5SOBANCNFSM4LR3V37Q .

forki commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 < notifications@github.com>:

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 https://github.com/fable-compiler/fable-react-native/issues/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 https://github.com/fable-compiler/fable-react-native/issues/59#issuecomment-602616343, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAOANF3PE5KGKV4X6F5HWLRI5UOTANCNFSM4LR3V37Q .

forki commented 4 years ago

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 sforkmann@gmail.com 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 < notifications@github.com>:

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 https://github.com/fable-compiler/fable-react-native/issues/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 https://github.com/fable-compiler/fable-react-native/issues/59#issuecomment-602616343, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAOANF3PE5KGKV4X6F5HWLRI5UOTANCNFSM4LR3V37Q .

Zaid-Ajaj commented 4 years ago

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.