Changed peer dependency in 1.0.9 about react-konva HOT 7 CLOSED

I published 1.0.10 with React >=15.0.0 <15.4.0 range.
And 1.1.0 with React ~15.4.0 range.

And for future safety you have to find a way not to depend on React internals.

Unfortunately, I don't know any possible implementations without using React internals.

Please reopen if I missed something.

from react-konva.

In fact it was even in patch version which is assumed only for bugfixes.

from react-konva.

I am not sure how semantic version works for that case. I wasn't able to google an answer. Please post a link if you can find.

The thing is - public API of react-konva itself didn't change.
So if you update react-konva AND react you will have backwards compatible change.

from react-konva.

Real life projects often use ~ to define dependency ranges in projects to minify chance of breaking a build, because minor version upgrades often could bring new bugs with new features.
So our build system got new patch update of react-konva, but react is still locked to 15.3.x.
Upgrading react to 15.4.0 requires special intention and testing.

Returning to peer dependency. It also can be treated as public API since it defines compatibility range. BTW you should define it as wide as possible to avoid issues with other libs that also defines same peer. I don't think that 1.0.9 introduced somth that couldn't work with react less 15.4.0.
So if you really need to shrink peer dep range support please consider do it at least with minor version. But it's better solution to extend this range as much as possible.

Semver maybe not cover exactly this question since it just general common sense rules. But I hope I have argued enough. Still will try find some links later.

from react-konva.

Thre is a note about updating dependency on semver FAQ:

What should I do if I update my own dependencies without changing the public API?
That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. I would usually expect additional code for the latter instance, in which case it’s obviously a minor level increment.

http://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api

It's not exactly same situation, but at least it suggests to have minor increment.

I would still suggest to publish patch version increment (1.0.10) with extended range of react. I am pretty sure that there is nothing that avoids using react-konva with react@^15.0.0 range,

from react-konva.

@Guria I can't extend the range of react versions. You can see change here: d4837af#diff-1f10719214e0d5e2a72f54b98f667499

from react-konva.

Ouch. Have you read release blogpost?

However, there is a possibility that you imported private APIs from react/lib/*, or that a package you rely on might use them. We would like to remind you that this was never supported, and that your apps should not rely on internal APIs. The React internals will keep changing as we work to make React better.

Anyway it was mistake to release this breaking change in patch version. Semver suggests a fix for such situations:

What do I do if I accidentally release a backwards incompatible change as a minor version?
As soon as you realize that you’ve broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backwards compatibility. Even under this circumstance, it is unacceptable to modify versioned releases. If it’s appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version.

But in your case it means we need 1.0.10 which will be the same as 1.0.8 with range of react >15.0.0 <15.4.0. And then release 1.1.0 or even 2.0.0 with ~15.4.0 range.

And for future safety you have to find a way not to depend on React internals.

from react-konva.