Un-deprecate non-strict YAML#3104
Conversation
AkihiroSuda
left a comment
There was a problem hiding this comment.
Thanks, but this might be considered as a breaking change
It is, but it has been deprecated for over 2 years now (since 0.12.0), and issuing a warning for over 2 years: #1045. So yes, it should be mentioned in the release notes. But if we never want to remove it, then we should maybe get rid of the deprecation warning and just print the non-strict YAML errors. |
|
For me it is quite normal to get warnings, when switching between alternative futures and the release version. If these are changed from warnings to errors, I would need to use a separate LIMA_HOME for experimenting... Which is "OK", I suppose. Can't say that it hasn't warned :-) ... will be unsupported in a future version ... |
Yeah, I was thinking the same thing this morning; it is an inconvenience for maintainers. So let's just remove the deprecation message, but keep it as a warning only. |
We still warn the user because it could be due to typos, but we no longer threaten to make strict mode the default. Allowing non-strict YAML is very useful for maintainers switching between feature branches. Failing on non-strict YAML would make it hard to e.g. delete instances that have been created by a different branch that introduces a new field. Signed-off-by: Jan Dubois <jan.dubois@suse.com>
5b2895a to
aee66fb
Compare
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [lima-vm/lima](https://github.com/lima-vm/lima) | patch | `v1.0.3` -> `v1.0.4` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>lima-vm/lima (lima-vm/lima)</summary> ### [`v1.0.4`](https://github.com/lima-vm/lima/releases/tag/v1.0.4) [Compare Source](lima-vm/lima@v1.0.3...v1.0.4) #### Changes - network: - Use MAC address as dhcpd identifier ([#​3123](lima-vm/lima#3123), thanks to [@​nirs](https://github.com/nirs)) - Updated gvisor-tap-vsock to v0.8.2 to [fix a DNS issue](containers/gvisor-tap-vsock#450) ([#​3133](lima-vm/lima#3133)) - YAML: - Un-deprecate non-strict YAML ([#​3104](lima-vm/lima#3104), thanks to [@​jandubois](https://github.com/jandubois)) - nerdctl: - Updated from v2.0.1 to [v2.0.3](https://github.com/containerd/nerdctl/releases/tag/v2.0.3) ([#​3134](lima-vm/lima#3134)) - Templates: - Updated to the latest revisions ([#​3134](lima-vm/lima#3134)) Full changes: https://github.com/lima-vm/lima/milestone/54?closed=1 Thanks to [@​afbjorklund](https://github.com/afbjorklund) [@​alexandear](https://github.com/alexandear) [@​jandubois](https://github.com/jandubois) [@​nirs](https://github.com/nirs) [@​olamilekan000](https://github.com/olamilekan000) [@​paulinek13](https://github.com/paulinek13) #### Usage ```console [macOS]$ limactl create [macOS]$ limactl start ... INFO[0029] READY. Run `lima` to open the shell. [macOS]$ lima uname Linux ``` *** The binaries were built automatically on GitHub Actions. The build log is available for 90 days: https://github.com/lima-vm/lima/actions/runs/12899702091 The sha256sum of the SHA256SUMS file itself is `05b809c6e23fa411fd6987c4fab1ceccb8efda36241130cc5269ba746a2a7762` . *** Release manager: [@​AkihiroSuda](https://github.com/AkihiroSuda) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMjIuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEyMi4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
We still warn the user because it could be due to typos, but we no longer threaten to make strict mode the default.
Allowing non-strict YAML is very useful for maintainers switching between feature branches. Failing on non-strict YAML would make it hard to e.g. delete instances that have been created by a different branch that introduces a new field.