-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backwards incomptaible change #306
Comments
Hey @hartbit thanks for reaching out about this. This was a conscious decision, see this comment for the reasons: #303 (comment) . But in hindsight i would not do that again and just stick to the conventions. So sorry for the inconveniences, will not happen again! Of course this is up to you and your team, but i would strongly encourage to always use pinned versions in your package.json, so something like this cannot happen. Best in combination with e.g. renovate and some sort of ci check in the pipelines. If you have any other problems with the library or feature requests, let me know :) |
Would it be possible, as a minor release, to reintroduce toDate as a synoym of toDateUTC? This would also cover the ^2.5.0 users out there, and be a non-breaking change. It could even be marked as being deprecated from v3 onwards ... Should just be a minor addition here? |
@edwardmjackson good point, i added toDate again in #314 |
I just wanted to let you know that version
2.6.0
includes backwards incompatible changes and should therefore have required a major version bump to follow semver. For example, in our team, we depend on^2.5.0
and a recentnpm install
broke our application becausenpm
rightfully downloaded version2.6.0
.According to semver's FAQ, one way to fix this issue would be to release a new minor version that restores the renamed functions (without removing the new ones): https://semver.org/#what-do-i-do-if-i-accidentally-release-a-backward-incompatible-change-as-a-minor-version.
The text was updated successfully, but these errors were encountered: