Release strategy for stable and beta versions

[rumkin]

EthereumJS VM packages are published with beta prereleases (example 5.0.0-beta.1) with the 'latest' dist-tag. What makes NPM to install this versions by default via npm i @ethereumjs/vm. To avoid this there should be some distinct dist-tag specified to prevent prereleases from being installed by regular users unintentionally. To do so it's enough to specify dist-tag on publishing like this:

npm publish --tag next

This will let users to install stable version e.g. 4.0.0 with npm install @ethereumjs/vm and to install version 5.0.0-beta.1 with npm install @ethereumjs/vm@next.

Motivation

Without such well known strategy users who depends on EthereumJS libraries don't know when to test their software for future versions compatibility. They also don't have an ability to install the future version without cloning the repo and investigating what changes are notable and will be published with the next version.

Proposal

1. Use next, beta, or unstable dist-tags to publish version of EthereumJS libraries before the stable version is published.
2. Define and publish in some well-known place this information, for example like electronjs do on it's main page.
   
3. Specify the list of possible prereleases e.g. (alpha, beta, rc or beta, nightly) to use in packages version.
4. Automate integrity checks to prevent accidental publishing with wrong tag or prerelease.

[holgerd77]

That's a super-good proposal especially with the concrete suggestions in the "Proposal" section. 😄 I am not completely grasping what is meant with 3., can you give an example here?

One specific note on the current beta releases: I am generally aware of the topic, to not overwrite the latest tag for the beta releases on this round was an intentional decision based on the special situation that we also switch package naming along with these release. My reasoning here was that in there are no current productive users on the new package names yet and so if they choose to install @ethereumjs/vm e.g. right now they'll likely know what they are doing. Just as some background on this.

I am currently fine-tuning my release experiences along the TODO lists on ethereumjs/ethereumjs-monorepo#907 (comment) (the tag question is actually also mentioned there). My suggestion would be that I would open a PR towards organization/docs with a more formalized and revised version of the TODO list and then we can also come back to this issue and integrate the ideas from here as well (or at least partly). Does this make sense?

[rumkin]

The 3rd point is about choosing some scheme of prerelease names which will be used in the project's versions like 1.0.0-beta.1. Some projects use alpha, beta, rc scheme and others nightly, beta scheme. Maybe it's reasonable to create own EthereumJS scheme. But there should be one ecosystem-wide scheme.

What's about @ethereumjs/vm. I understand this, and this proposal is mostly for future releases.

My suggestion would be that I would open a PR towards organization/docs with a more formalized and revised version of the TODO list and then we can also come back to this issue and integrate the ideas from here as well (or at least partly). Does this make sense?

Definitely 👍