Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Version 3.0.7 is a breaking change! It should upraise MAJOR version.
See original GitHub issueMain class CanvasRenderService in 3.0.7 is replaced by ChartJSNodeCanvas. It is a real breaking change and MAJOR version of package should be upraised to 4.x.x.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:7
- Comments:8 (4 by maintainers)
Top Results From Across the Web
Release cycle / version numbers / breaking changes
If the next version is clearly not a major version, breaking changes must not be merged under any circumstances.
Read more >Breaking change in previous major release - Stack Overflow
When you claim to be applying semantic versioning, you MUST not release a breaking change without bumping the major version number.
Read more >Types of breaking changes - .NET - Microsoft Learn
NET attempts to maintain compatibility for developers across .NET versions, and what kind of change is considered a breaking change.
Read more >Planned breaking changes in version 3.0 | Pact Docs
Rename pacticipant to application · Removal of deprecated relations without a pb · Remove option to order by semantic version. · Rename failed...
Read more >Breaking Changes | Electron
Breaking changes will be documented here, and deprecation warnings added to JS code where possible, at least one major version before the change...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
The only other solution I can think is if 3.1 can support both signatures for the constructor, this would be the best compromise as it should break nobody but still allow a clean move to 4.0.x
I had a look through some dependants versions and along with the npm stats I think your suggestion will limit the problem to the least number of people, as well as any future installs of version
3.x.x.I like the idea of both signatures for this stopgap release, I will investigate that now and try see what I can do, otherwise deploy a rollback version and new version
4.0.0