nivida
commented
5 years ago The most recent one effecting my projects is #2570 wherein a change was made to suddenly start returning the BigNumber object again, instead of the number as string as it had been for at least the past year.
I had to return the BigNumber object because of another issue with a React native production build.
bignumberObj.toString() and you will have the same return value as before. I think it's very important that a production build with the widely used React native is working.
Thirdly a long time ago it actually used to return the BigNumber object and this was changed for good reason.
The complete BigNumber handling in the entire space has problems because some projects are using BN.js and some others are using Bignummber.js object. My goal is to change to the native BigInt implementation and to talk with Richard from ethers.js to do that too. (we use the AbiCoder from ethers.js)
again with literally 0 warning, just a note to someone who asked where it went saying "we don't support it anymore".
This was announced here: https://twitter.com/web3_js/status/1088875148206358528
If someone wants to build from source they can just checkout the project on github and get the latest and greatest "bleeding edge" code to play with.
Generated files like a minified full bundle will never be a part of this GitHub repository but I will definitely add it to the NPM package. I've removed it because of security reasons and the bundle size. I would be happy to have full control over the used dependencies in my DApp.
But at present, without webpack there is no way to get a recent minimized version for testing.
It's possible to use Web3.js without webpack on a node.js environment :-)
Beta is a time to go slowly and carefully over the known bugs in order of severity and hammer them out.
The feedback I got until now was mostly the other way around because we all are waiting for a long time on the stable release.
Could you give me a list of breaking changes by side of these two?
We don't need a release every 7 to 10 days.
We need that otherwise, we will not have a stable release in the first half of this year. I was not just doing releases because of fun. Mostly there are 100-200 commits and 10-20 closed issues. I was working as much as I can to improve this library.
Encourage him to involve the community in any decision / fix / whatever that breaks existing functionality and to seek alternatives even when he's certain there are none.
I invited the whole community in the beta.38 release to be involved in the draft gist files I've referenced there and I've also invited the community to give feedback over the issue list. I'm not sure if there is anything more I could do.
An updated roadmap to 1.0-RELEASE needs to be discussed, formalized, adopted and released by the community. This roadmap should list all existing functionality and any planned functionality preferably in as much detail as possible.
This is explained here: https://twitter.com/web3_js/status/1088875148206358528
If a unit test needs to be updated, there needs to be discussion about what the change is and why it is necessary.
This is possible but would slow down the process extremely. Feel free to be a part of the PR processes as some others already doing. I'm still wondering about which list of breaking changes you are talking.
A roadmap to 2.0-RELEASE needs to be discussed, formalized etc as in step 1. Anything found during development of 1.0 that would break 1.0-RELEASE's testing regime should be scheduled for a 2.0 target.
There are no breaking changes planned. The BigNumber breaking change did happen because I fixed a bug.
The only exception to steps 1..4 should be verifiable emergency security fixes where money or other items of value are put at risk if the fix is not in immediately.
Or a non-working production build of a widely used framework.
This is important, as time progresses the current development style on this project makes it harder and harder to actually use reasonably current versions.
Should we go back to the old development style where close to no one worked on this project?
Consider for a moment, that metamask is still using 0.2x and a large part of their reasoning is exactly this moving target approach that has been the norm for so long that they literally stopped trying.
Metamask is still using 0.2.x because they want to use the last stable version for their in production used product.
It's so hard to do the correct thing for everyone. Some months ago anyone was blaming me because of the missing process and now I get blamed for fixing and improving the library. I really don't know how big my motivation will be in the next six months if this blaming doesn't stop.
szerintedmi
levino
sshelton76
biocrypto730
Description
I developed a project based on web3js and @nivida keeps fast tracking breaking changes. The cost to our development budget thus far since he has taken the lead is in excess of $150k
Expected behavior
When a project, especially a framework or tool that the entire world is trying to build upon, is in beta, the expectation when pulling in the beta release is to fix existing bugs without making ANY breaking changes unless they are immediate, severe security concerns that cannot be addressed in any other way.
If something is broken and simply cannot be fixed without breaking contract / API, then you are supposed to deprecate the broken thing and give developers time, such as 90 days to upgrade their code to the new, shiny hopefully unbroken thing. This has not been occurring on this project and the costs to my development budget alone have exceeded $150k since December just trying to keep up.
Actual behavior
It appears that @nivida has been making broad sweeping, breaking changes without any consultation with the community which is trying to build on top of this thing. The most recent one effecting my projects is https://github.com/ethereum/web3.js/issues/2570 wherein a change was made to suddenly start returning the BigNumber object again, instead of the number as string as it had been for at least the past year.
This change causes enormous problems for us, and I am certain it does for anyone who is putting serious time, money and effort into developing on top of web3js. Yet the only justification is he couldn't get react to build.
First off, not everyone is using webpack, or react as part of the build process.
Secondly, most of the people who are using react already had workarounds in place as evidenced by the large body of working react code @nivida managed to break.
Thirdly a long time ago it actually used to return the BigNumber object and this was changed for good reason.
The reasoning for the original change as I recall is that strings are easier to deal with and less messy to marshal around until you actually have to do math, at which time there are a number of libraries at your disposal if you have a string representation, but with BN you are stuck with BN and all of its shall we say "quirks". https://github.com/ethereum/web3.js/issues/2675 Did something fundamental change to remove those concerns?
In the meantime those of us who are trying to stay current while building things people and systems will interact with everyday, must now, yet again refactor enormous amounts of code and tests just to have the privilege of having some actually important bugs like transaction signing fixed.
This is not the only example...
There are many people who are still stuck on beta-37 after an arbitrary decision was made to eliminate the minified version from the release cycle, again with literally 0 warning, just a note to someone who asked where it went saying "we don't support it anymore". Then a further comment some months later saying it would return because he didn't realize how vital it was to people. https://github.com/ethereum/web3.js/issues/2623 It has yet to return
What is even the point of cutting a release, beta or otherwise if it must be built by the end user?
If someone wants to build from source they can just checkout the project on github and get the latest and greatest "bleeding edge" code to play with.
I'm not saying there aren't some security issues from shipping a completed and minified version, but those are minor in comparison to everyone + dog needing to build locally. At least with a minified version on a CDN, one can check the hash to verify its authenticity, directly in the browser before it loads. https://www.w3.org/TR/SRI/ Which frankly you're insane if you're not doing it already. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
Not everyone wants to use webpack, it's huge, it slows down development and 90% of the things it's used for, you'd be better off using a simpler solution like yarn or insert tool dejour
But at present, without webpack there is no way to get a recent minimized version for testing. This is causing many people to fall behind and also alienating a significant number of people who could be helping to test if there were just a single thing to import, instead of having to rebuild world every 7 to 10 days.
I could go on and on, but the point is... This is a BETA. Beta is not the time to be bold, move quickly and break things. Beta is a time to go slowly and carefully over the known bugs in order of severity and hammer them out. Either one by one or as part of a larger class of fixes. It is a time for bug reports and bug fixes, but not breaking changes.
Yes one could argue that code not quite meeting a documented spec counts as a bug. But if you're breaking things people are currently using and have been using successfully for over a year, you're doing it wrong, so please stop doing it.
Steps to reproduce the behavior
Look at the issues since beta-32 that have been addressed by @nivida
Congratulate him on the items he managed to fix without breaking other things, there are hundreds. But every release cycle something has managed to break and usually that something was working before. This is a serious problem.
Caution him to slow down, look long and hard at the problems and the potential solutions and be more careful in the future. We don't need a release every 7 to 10 days. We should be shooting for a max of one a month, well tested with nothing new getting broken in the process.
Encourage him to involve the community in any decision / fix / whatever that breaks existing functionality and to seek alternatives even when he's certain there are none.
Recommended Fix
Honestly, at this point I'm just going to maintain my own fork of web3.js in order to focus on stability. I'll just back port fixes when they actually fix their intended target without breaking existing functionality. In the meantime I'd like to see the community take a more formalized approach to software development in general that looks something like this.
An updated roadmap to 1.0-RELEASE needs to be discussed, formalized, adopted and released by the community. This roadmap should list all existing functionality and any planned functionality preferably in as much detail as possible.
A code freeze needs to be called for a short time, no new features, no breaking of existing features. Unit and integration and regression tests need to be written and updated for all functionality (currently showing 95% coverage which isn't bad, but how in depth are those tests and why is there 5% of the codebase without coverage?). Once tests have been written they need to be an integral part of the build process and commits which break any test should not be pulled in at all. From here an unfreeze can be called to implement remaining features on the roadmap, ensuring that tests are always maintained and essentially frozen in time from the developers perspective. This gives the developers using the code a contract that they can rely on to build first class products to showcase the power of the platform.
If a unit test needs to be updated, there needs to be discussion about what the change is and why it is necessary. A simple "this test no longer reflects the reality of our implementation", should be enough to start the conversation, but we should be talking about how and why the implementation eventually differed from the roadmap and test. What is the impact of this change? If it turns out the test was implemented incorrectly or only partially implemented then of course it should be updated. Otherwise this can be assumed to be a breaking change and should be roadmapped to a later release.
A roadmap to 2.0-RELEASE needs to be discussed, formalized etc as in step 1. Anything found during development of 1.0 that would break 1.0-RELEASE's testing regime should be scheduled for a 2.0 target.
The only exception to steps 1..4 should be verifiable emergency security fixes where money or other items of value are put at risk if the fix is not in immediately.
This is important, as time progresses the current development style on this project makes it harder and harder to actually use reasonably current versions. Consider for a moment, that metamask is still using 0.2x and a large part of their reasoning is exactly this moving target approach that has been the norm for so long that they literally stopped trying.
Thanks for taking the time to read this. I do appreciate @nivida and his hard work on this project. I just think it's time to formalize certain aspects of development which will lead to a stronger product overall. If nothing else I'd like to implore @nivida to open issues when he uncovers the need for potential breaking changes, but instead of shooting from the hip he should gather community feedback on the necessity of the change and try to identify potential alternatives, then give a reasonable timeframe for anything that would require deprecation.
Doing so would be a huge help to all the people who are serious about building on top of this.