Update cuelang.org/go to v0.9.1#401
Conversation
|
@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 |
Let me come back to you to confirm whether you should set |
|
@myitcv I guess the version in module.cue is like for Go, and sets the minimum version supported? For example, a module with |
Correct, I just wanted to double check our plan with respect what To confirm, in CUE v0.9.1, 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. |
In so doing, set cue/load.Config.AcceptLegacyModules when loading modules, to allow pre-existing Timoni modules (which don't have a language.version field) to be loaded. For more information see https://cuelang.org/issue/3219 Note that https://cuelang.org/issue/3222 tracks making a change in a later CUE release that will "fix" the language.version implied by AcceptLegacyModules. This is not significant right now, because there are not yet any language changes guarded by language.version, but it will become significant when such changes are introduced.
cuelang.org/go v0.9.1cuelang.org/go v0.9.1
cuelang.org/go v0.9.1cuelang.org/go to v0.9.1
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