Update process docs to reflect recent changes to release process #14091
Conversation
sbc100
force-pushed
the
new_process
branch
2 times, most recently
from
93336d1
to
99ce106
Compare
There was a problem hiding this comment.
I guess what's not documented here yet is the expectation that we'll be creating the candidate builds manually (or via a script) with a CL in emscripten-releases. But that doesn't need to be in this PR, and this process can just as easily be used to release non-LTO builds.
| Current Trunk | ||
| ------------- | ||
| 2.0.20 | ||
| ------ |
There was a problem hiding this comment.
It would be good to mention that from here the value in emscripten-version.txt in git is forward-looking etc.
I feel like we should document this elsewhere too - perhaps on the "developer guide" page on the website?
There was a problem hiding this comment.
I added a description to the ChangeLog. I honestly can't think of any use case that might be effected by this? At least none of our processes were. I'm not sure who it would benefit to document this outside of where we already have.
There was a problem hiding this comment.
The risk is low, I agree. But one possible issue is people bisecting on the emscripten repo and looking at the version file as they go. I think it's useful to mention that file's meaning has changed at this time.
There was a problem hiding this comment.
I have mentioned it in this ChangeLog entry.. do you think I should mention it in the bisect instructions too?
There was a problem hiding this comment.
Maybe not needed in bisection. The docs there focus on multirepo bisection, which this should not affect.
If there is confusion we can update the docs accordingly later.
Ask discussed the new plan is to have the version stored on `main` reflect the next upcoming, but unreleased, version of emscripten. This matches, for example, llvm where the git users see version N+. The hope is that this means that we can tag that exact commit that goes into an emsdk releases rather than the next commit, and it should avoid tree closures.
| Current Trunk | ||
| ------------- | ||
| 2.0.20 | ||
| ------ |
There was a problem hiding this comment.
The risk is low, I agree. But one possible issue is people bisecting on the emscripten repo and looking at the version file as they go. I think it's useful to mention that file's meaning has changed at this time.
|
Maybe I'll shoot a PSA to the mailing list.. |
As discussed the new plan is to have the version stored on
mainreflect the next upcoming, but unreleased, version ofemscripten. This matches, for example, llvm where the git
users see version N+.
The hope is that this means that we can tag that exact commit
that goes into an emsdk releases rather than the next commit,
and it should avoid tree closures.