You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 5, 2025. It is now read-only.
Copy file name to clipboardExpand all lines: RELEASE.md
+56-81Lines changed: 56 additions & 81 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,43 +22,24 @@ Further details about versioning can be found in the [semver 2.0.0 specification
22
22
23
23
### Major
24
24
25
-
1. The release should get released as an `RC` version on the specified track below.
26
-
1. The minor `RC` version stays released for a `month` for testing purposes.
27
-
1. During release review, the code is frozen unless new changes are proposed, approved and merged.
28
-
1. Changes should trigger a new `RC` release and set the release clock back a `week` so reviewers have the time they need to test new changes.
29
-
1. The project lead should manually test the `RC` against a Node project and the published
30
-
minified bundle in a browser context. An external reviewer should verify they have done the same.
25
+
1. The release should get released as an `legacy-dev` version on the specified track below.
26
+
2. The major `legacy-dev` version stays released for a `month` for testing purposes.
27
+
3. During release review, the code is frozen unless new changes are proposed, approved and merged.
28
+
i. Changes should trigger a new `legacy-dev` release and set the release clock back a `week` so reviewers have the time they need to test new changes.
31
29
32
30
### Minor
33
31
34
-
The `minor` release inherits the rules from the `major` release but has a smaller testing phase of one `week` and the release clock will be set back `2 days` on a change of the published code.
32
+
The `minor` release inherits the rules from the `major` release but has a smaller testing phase of 3 days and the release clock will be set back `2 days` on a change of the published code.
35
33
36
34
### Patch
37
35
38
36
Since November 2019, Web3 has been following the `minor` rules for `patch` as well, to help establish a series of non-breaking releases.
39
37
40
38
## Prereleases
41
39
42
-
### Release Candidate
40
+
### Legacy-dev Release ( Release Candidate )
43
41
44
-
A release candidate gets published on the `rc` track and is no longer under active development. A release candidate gets released with the version number defined in the [semver 2.0.0 specification](https://semver.org/) specification.
45
-
46
-
### Beta Release
47
-
48
-
A `beta` release gets published on the `beta` track and is under active developemnt. The version number of the `beta` release gets defined as specified in the [semver 2.0.0](https://semver.org/) document.
49
-
50
-
## Long Term Support (LTS)
51
-
52
-
> Note: This section has not yet been decided and so for now is purely informative.
53
-
54
-
To provide safety over longer periods, it is important to have versions tagged as `LTS`.
A Legacy-dev release gets published on the `legacy-dev` track and is no longer under active development. A release candidate gets/Legacy-dev released with the version number defined in the [semver 2.0.0 specification](https://semver.org/) specification.
62
43
63
44
## Deprecation Rules
64
45
@@ -72,60 +53,54 @@ Because breaking changes are always happening during the development of a projec
72
53
73
54
The following describes the steps required to release a new version of `web3.js`. It is followed to adhere to community standards and expectations.
74
55
75
-
## Release Candidate (RC) Release Procedure
76
-
77
-
1. Create a GitHub draft release.
78
-
1.[Example](https://github.com/ethereum/web3.js/releases/tag/v1.2.7-rc.0) - should contain at a minimum: release notes, changelog, any other important notes.
79
-
1. Request review on the draft release from a web3.js contributor ([@cgewecke](https://github.com/cgewecke)) for completeness, grammar, etc.
80
-
1. Create release branch (e.g. `release/1.2.7`).
81
-
1. Update and commit `CHANGELOG.md`.
82
-
1. Move section header `[Unreleased]` to bottom.
83
-
1. Add next anticipated release version number to bottom (as a placeholder for new changelog entries).
84
-
1. In the project root, run `npm run build` and commit changes after using a commit message like: `Build for 1.0.0-rc.0`
85
-
1. The next step will also build each package, but Lerna makes the tagged commit before building the packages (so they're not included)
86
-
3. Create release commit and tags e.g. `lerna version 1.2.7-rc.0 --no-push`
87
-
1. (updates package version numbers, builds minified file (for `1.x`), creates release commit and tags.)
88
-
4. Push release branch to origin with tags `git push origin release/1.2.7 --follow-tags`.
89
-
5. Create release PR as draft ([example](https://github.com/ethereum/web3.js/pull/3351)).
90
-
6. Ensure CI is green / passing.
91
-
1. (spend time here inspecting the CI logs to ensure everything looks valid and results were reported correctly)
92
-
7. Run `npm run publish from-package -- --dist-tag rc`.
93
-
1. Lerna can sometimes have difficulty with the number of packages we have. If the above command is unsuccessful, for every unpublished package run: `lerna publish --scope="package-name"``npm dist-tag add <package-name>@<version> rc`)
56
+
# 1.x Future releases
57
+
As web3.js v4 published so everyone is requested to migrate to web3.js v4. Web3.js v1 will only get critical security updates and will follow tags:
58
+
- `legacy` : for v1 main releases
59
+
- `legacy-dev` : for v1 test/RC releases, this is replacement of `rc` tag
60
+
61
+
## Legacy Dev (Release Candidate) Release Procedure
62
+
63
+
1.`git checkout 1.x` and `git pull`: Verify you are on the `1.x` base branch.
- Spend time here inspecting the CI logs to ensure everything looks valid and results were reported correctly.
84
+
12. When sufficient approvals are given, publish draft release created in `Step 9`
85
+
13. Publish release on npm using `npm run publish from-package -- --dist-tag legacy-dev`.
86
+
1. Lerna can sometimes have difficulty with the number of packages we have. If the above command is unsuccessful, for every unpublished package run: `lerna publish --scope="package-name"``npm dist-tag add <package-name>@<version> legacy-dev`
87
+
14. Keep same PR open for formal release after few days based on rules defined in this document.
88
+
89
+
90
+
## Formal Release Procedure for legacy v1 release
91
+
92
+
1. Checkout release branch (e.g. `release/1.10.4`) created during legacy-dev release `step 2`.
93
+
2. Verify all dependencies have been installed using `npm i` and commit changes.
94
+
- If you are already in release branch dir, created for `legacy-dev` and no changes are made after it, you can skip step 1 and step 2
95
+
3. Build library and bump versions using: `lerna version 1.10.4 --force-publish --no-push --no-private --no-git-tag-version`
96
+
4. Commit all changes into release branch with commit message like `build for release 1.10.4`
97
+
5.`git tag bumped-version`: Tag the commit with bumped version having prefix `v` , e.g. `git tag v1.10.4`
98
+
6. Push release branch to origin `git push origin release/1.10.4`.
99
+
7. Push release tag created in `Step 5` to `origin` using `git push origin --tags`
94
100
8. Publish the GitHub release.
95
101
9. A GitHub Webhook should trigger the ReadTheDocs build after the release is published.
96
-
1. (The build may sometimes need to be manually triggered in ReadTheDocs admin panel. If the version does not appear, create a build of a previous version to refresh the list.)
97
-
1. Activate the new version.
98
-
10. Request PR review from key contributors:
99
-
1. Chris from EthereumJS ([@cgewecke](https://github.com/cgewecke))
100
-
1. Patricio from Nomic Labs ([@alcuadrado](https://github.com/alcuadrado))
101
-
1. Michael from Embark ([@michaelsbradleyjr](https://github.com/michaelsbradleyjr))
102
-
1. Nicholas from Truffle ([@gnidan](https://github.com/gnidan))
103
-
1. If touches or affects ENS: Nick Johnson ([@Arachnid](https://github.com/Arachnid))
104
-
11. Wait 1 week for community discourse and 2 reviewer approvals.
105
-
1. (if release is an emergency patch, time limit may be reduced relative to severity.)
106
-
107
-
## Formal Release Procedure
108
-
109
-
1. Create GitHub draft release from text of `rc` release.
1. Create and push release commit and tags: `lerna version 1.2.7 --force-publish --no-push`
112
-
1. Push release branch to origin with tags `git push origin release/1.2.7 --follow-tags`.
113
-
1. Publish the GitHub release.
114
-
1. A GitHub Webhook should trigger the ReadTheDocs build after the release is published.
115
-
1. (The build may sometimes need to be manually triggered in ReadTheDocs admin panel. If the version does not appear, create a build of a previous version to refresh the list.)
116
-
1. Activate the new version.
117
-
1. Set the version to default.
118
-
1. Run `npm run publish from-package`.
119
-
1. Merge release PR.
120
-
1. Share the release announcement on:
121
-
1. (_Note:_ There is a delay on npm between different regions, so all may not see the release immediately.)
122
-
1. Twitter
123
-
1. Gitter
124
-
1. Ethereum JavaScript Community (EJC) Discord
125
-
1. Reddit
126
-
1. Depending on release's significance to certain projects, write to:
127
-
1. Fabio from 0x ([@fabioberger](https://github.com/fabioberger))
128
-
1. Santiago from OpenZeppelin ([@spalladino](https://github.com/spalladino))
129
-
1. Pedro from WalletConnect ([@pedrouid](https://github.com/pedrouid))
130
-
1. Josh from FunFair ([@joshstevens19](https://github.com/joshstevens19))
- (The build may sometimes need to be manually triggered in ReadTheDocs admin panel. If the version does not appear, create a build of a previous version to refresh the list.)
103
+
- Activate the new version.
104
+
- Set the version to default.
105
+
10. Run `npm run publish from-package -- --dist-tag legacy`, it should be `legacy` tag.
0 commit comments