|
61 | 61 | adding the version and the hash. Updating the "latest" tag there to the new |
62 | 62 | release is possible, but can also be deferred if you want to do more testing |
63 | 63 | before users fetching "latest" get this release. |
64 | | -2. Tag the emscripten repo on the emscripten commit used by that release (which |
65 | | - you can tell from the DEPS file), using something like |
66 | | - `git checkout [COMMIT]` ; `git tag [VERSION]` ; `git push --tags`. |
67 | | -3. Tag the emsdk repo as well, on the commit that does the update, after it |
| 64 | +2. Tag the emsdk repo as well, on the commit that does the update, after it |
68 | 65 | lands on master. |
69 | | -4. Update |
| 66 | +3. Update |
70 | 67 | [emscripten-version.txt](https://github.com/emscripten-core/emscripten/blob/master/emscripten-version.txt) |
71 | 68 | in the emscripten repo. This is a delayed update, in that the tag will refer |
72 | 69 | to the actual release, but the update to emscripten-version.txt is a new |
|
77 | 74 | when that's unlikely, etc. |
78 | 75 | * There is no need to open a PR for this change, you can optionally just |
79 | 76 | commit it directly. |
80 | | - |
| 77 | +4. Tag the emscripten repo on the emscripten commit on which |
| 78 | + `emscripten-version.txt` was updated. (This could also be the commit from the |
| 79 | + DEPS file as well, but this way is less confusing when just working on the |
| 80 | + emscripten repo, and the difference should only be one commit anyhow.) |
81 | 81 |
|
82 | 82 | Major version update (1.X.Y to 1.(X+1).0) |
83 | 83 | ----------------------------------------- |
|
0 commit comments