@@ -54,25 +54,25 @@ Requirements:
54
54
How:
55
55
56
56
1 . Pick a version for a release and make sure it meets the requirements above.
57
- Let this version SHA be <non-LTO-sha >.
57
+ Let this version SHA be ` <non-LTO-sha> ` .
58
58
1 . If we want to do an LTO release as well, create a CL that copies [ DEPS] [ DEPS ]
59
59
from <non-lto-sha > to [ DEPS.tagged-release] [ DEPS.tagged-release ] in
60
60
[ emscripten-releases] [ releases_repo ] repo. When this CL is committed, let the
61
- resulting SHA be <LTO-sha >. An example of this CL can be
61
+ resulting SHA be ` <LTO-sha> ` . An example of this CL is
62
62
https://chromium-review.googlesource.com/c/emscripten-releases/+/3781978 .
63
63
1 . Run [ ` ./scripts/create_release.py ` ] [ create_release ] in the emsdk repository.
64
64
When we do both an LTO and a non-LTO release, run:
65
65
```
66
66
./scripts/create_release.py <LTO-sha> <non-LTO-sha>
67
67
```
68
- This will make the <LTO-sha > point to the versioned name release (e.g.
69
- ` 3.1.7 ` ) and the <non-LTO-sha > point to the assert build release (e.g.
68
+ This will make the ` <LTO-sha> ` point to the versioned name release (e.g.
69
+ ` 3.1.7 ` ) and the ` <non-LTO-sha> ` point to the assert build release (e.g.
70
70
` 3.1.7-asserts ` ). When we do only a non-LTO release, run:
71
71
```
72
72
./scripts/create_release.py <non-LTO-sha>
73
73
```
74
- This will make the <non-LTO-sha > point directly to the versioned name release
75
- (e.g. ` 3.1.7 ` ) and there will be no assert build release. If we run
74
+ This will make the ` <non-LTO-sha> ` point directly to the versioned name
75
+ release (e.g. ` 3.1.7 ` ) and there will be no assert build release. If we run
76
76
[ ` ./scripts/create_release.py ` ] [ create_release ] without any arguments, it
77
77
will automatically pick a tot version from
78
78
[ emscripten-releases] [ releases_repo ] repo and make it point to the versioned
0 commit comments