Replies: 1 comment 1 reply
-
Yes, light-breaking (or and most, no-breaking) is the goal. Since I moved from ES3 to modern JS, there were lots of new features I could use (sorry Internet Explorer uses ;)). The biggest obviously being BigInt, which was going to be a huge change for everyone. Going forward there are two huge advantages to how v6 was organized:
But I agree, it was the most intense migration for most and one I’d prefer to avoid again. Also, I will start releasing v7 betas within a week or so. I’d love early feedback. :) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
First of all, I would like to thank you for making ethers.js-V6.
V6 has excellent features like ES2020-bigint's and V6 has become a critical piece of the nomo-webon-kit.
However, many devs in our company are still struggling with the migration from V5 to V6.
Of course we want to use latest JS-features, but I feel like some the deprecations were too fast (see #4289 and #4312).
So my hope is whether it would be possible to make ethers.js-V7 a "light breaking" release where most of the documentation remains valid?
In my opinion, the documentation has been a huge mess during the V5 -> V6 migration, and we cannot expect all Stackoverflow-posts, all tutorials and all LLM-AI-answers to be rewritten every year.
I have no problem with breaking changes in general, however, I am trying to avoid a situation where all the documentation gets thrown into the garbage every year.
Beta Was this translation helpful? Give feedback.
All reactions