Backwards incomptaible change

[hartbit]

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 recent npm install broke our application because npm rightfully downloaded version 2.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.

[co-sic]

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 :)

[edwardmjackson]

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?
https://github.com/gastromatic/calendar-date/blob/main/src/CalendarDate.ts#L267

[co-sic]

@edwardmjackson good point, i added toDate again in #314