A request for a return to semantic versioning

[wbt]

Those of us who use web3 would really appreciate greater predictability around breaking changes.

As noted here,

I am just happy that we are abandoning calling everything a betaX while making drastic API changes.

web3 does not appear to be abandoning that practice. Starting with the release of 2.0.0-alpha, I'm anticipating a 2.0.0-alpha2, 2.0.0-alpha3, etc. with breaking changes likely between (for example) 2.0.0-alpha21 and 2.0.0-alpha22.

This Issue is a specific strong request to return to semantic versioning.

Can we please use a version number in the form Major.Minor.Patch where a major version increment implies breaking changes, a minor version increment implies new functionality implemented with full backward compatibility, and a patch version increment implies bugfixes with full backward compatibility?

For example, we have 2.0.0-alpha. Let's assume for the sake of discussion that it's imperfect, or even that it's somehow magically perfect. Either way, call it 2.0.0. When issues are discovered and fixed, bump up one of those three numbers according to the extent of the change, as noted above, instead of tacking some number on the end after "alpha." There's no need to call 2.0.0 stable, especially if it isn't. Maybe we'll be ready to call 2.0.2 stable. Maybe it'll be up to 2.5.7 before then. Maybe we'll be a year out and at version 5.12.73 before it's ready to be called stable. Who knows?

Let's not create unrealistic expectations of how much @nivida can power through in whatever alternative definition of "asap" or "soon" this project happens to be using. We don't want to burn anybody out. Let's also not continue the kind of chaos that resulted from the 1.0.0-betaX series, with breaking changes getting rolled out on an increment smaller than patch. If the software is ready to be called stable soon, great. If not, just bump up the appropriate part of the version number to match the specific bit(s) of functionality as they are developed and rolled out.

If adopted, this would be a much more sustainable mode of software development for both web3 and everyone who depends on it.

Thanks for your work!

[VexyCats]

I support this 100%. Please use semver moving forward from here out....

[nivida]

Issue #2961 does explain it.

[wbt]

From the comment there:

2.0 got released as 2.0.0-alpha and will get patches in the next months until I've written down the spec for it and until we have jointly defined how the future API and architecture will be.

Can we please return to semantic versioning right away, with 2.0.0-alpha => 2.0.0 and use semver from there, updating the major version number with breaking changes to the API? It's perfectly fine if 2.0.0 doesn't get much or any actual use. It's fine if the API doesn't reach stability until 78.0.0 or 1481.0.0 or something like that. In the progress toward that result, using semver along the way instead of putting everything on the a sub-patch tag number would be a huge help!

I understand a desire to not get locked down into imperfect current API and architecture but rather move toward something better in the future, but that can be accomplished by just clearly stating that it's not stable or long-term and that future architecture is still in the works; expect rapid increases in the major version number. We are not in any danger of running out of integers for major version numbers, even if you go up a major version number every day.