Use region replacements for release/dev rust toolchain versions #284
Conversation
Veetaha
force-pushed
the
feat/replace-toolchain-region
branch
from
3a57797 to
8643e41
Compare
Veetaha
force-pushed
the
feat/replace-toolchain-region
branch
from
8643e41 to
4d12096
Compare
| @@ -5,13 +5,11 @@ set -euo pipefail | |||
| script_dir=$(readlink -f $(dirname ${BASH_SOURCE[0]})) | |||
|
|
|||
| . $script_dir/../lib.sh | |||
There was a problem hiding this comment.
At first, it confused me, that the set-version script also updated the toolchain, but this makes total sense. Do we maybe want to rename the file to update-stable-regions or something similar?
There was a problem hiding this comment.
I can't come up with a better name. It should be update-stable-regions because it updates regions with dev and unstable as well. I'll keep it as set-version.sh and re-visit this in scope of #286
| -o -name "*.ps1" \ | ||
| \)\ | ||
| )) | ||
| replace_date_in_regions "rust toolchain release" "$rust_toolchain" |
There was a problem hiding this comment.
Further down, there is an if statement which conditionally replaces the version for dev or stable. Should we maybe to the same separation here? I imagine, we only want to do this replacement, when a stable version is released 🤔
There was a problem hiding this comment.
Yeah, an unstable version release will be a special-case. In that case, we shouldn't update the toolchain versions in the docs, but we should update it in the installation scripts, and then return back the previous version in the installation scripts when the next dev version commit is made so that master version of the script continues to install the latest released marker version with its toolchain.
I don't like where it goes...
I'm thinking that what if we have a mutable master pre-release that we update every time a new commit is merged to master. For example, like it is done here.
Then the master installation script would install the true latest dev version of marker pre-compiled binaries, and it can use the latest toolchain version we have in the repo.
For example, if someone reported a bug, and we fixed it in master, we closed the issue. Then we can ask the user who reported the issue to check if it works for them by installing the master build of marker binaries and using a git dependency in their marker_api, and if the problem still exists they can reopen the issue after that testing.
There was a problem hiding this comment.
I created an issue #286.
But for now, I'll try to think of a crutch here..
There was a problem hiding this comment.
The crutch that I'm thinking off would require an additional git commit to revert the change in the toolchain version in the installation script. That by itself would require some effort to implement that I'd rather spend on #286. Let's say that for now doing a pre-release will suffer from the problem that the toolchain version in master for installation scripts is updated to the current one. It's easy to fix it manually be returning back the changes to the toolchain version made by the release process in master. I just assume that we'll do a pre-release soon.
scripts/replace-in-regions.sh
Outdated
| # Replace both the version itself, and the sliding tags | ||
| # | ||
| # There is a caveat here for the major version. It is rather ambiguous, because | ||
| # it is just a single number, there are no dots in it that could identify it as | ||
| # semver version. So for the major version we require that it is always specified | ||
| # with the `v` prefix e.g. `v1`. |
There was a problem hiding this comment.
This comment can be removed, since it applies to the function below, and it's already mentioned in the doc comment of that one
There was a problem hiding this comment.
Yeah, forgot to remove the comment, thanks!
This is a prerequisite for #281.
I updated the
set-version.shscript to automatically use the rust toolchain version specified inrust-toolchain.tomlduring the release process, and also made theupdate-toolchain.shupdate the specificdevregions where the toolchain version is mentioned for the next dev cycle.