Closed myitcv closed 1 week ago
@myitcv this looks great! Big thanks for the fix.
Great, thanks. Just to re-emphasise: please DON'T submit this PR. We'll tag v0.9.1 tomorrow (assuming we don't run into any other issues that need fixing). At which point we can re-do the PR to use the actual v0.9.1 release.
@stefanprodan do you think new modules should start adding 'language: version: v0.9.1' as well?
@errordeveloper yes the blueprints used by timoni mod init
will have the language version after next release.
'language: version: v0.9.1' as well?
Let me come back to you to confirm whether you should set language: version: "v0.9.0"
or language: version: "v0.9.1"
(assuming that is you upgrade to v0.9.1 when it is released).
@myitcv I guess the version in module.cue is like for Go, and sets the minimum version supported? For example, a module with language: version: "v0.9.0"
will work with CUE v0.10.0?
@myitcv I guess the version in module.cue is like for Go, and sets the minimum version supported? For example, a module with
language: version: "v0.9.0"
will work with CUE v0.10.0?
Correct, I just wanted to double check our plan with respect what cue mod init
will do when we release v0.9.1 (because that's effectively the command that you are emulating in Timoni).
To confirm, in CUE v0.9.1, cue mod init
will include the following line:
language: version: "v0.9.0"
So Timoni should do the same. Please feel free to mark this hard-coding as a "TODO" on your side, because we are also going to expose the following via public API:
At which point you can remove the hard-coding.
This PR only exists to verify a change that will be released as part of cuelang.org/go@v0.9.1. Specifically, it enables a compatibility mode where legacy modules (which do not have a language.version field) can be consumed.
For more information see https://cuelang.org/issue/3219