proposed:
this was the final PR cleaning up various bits/loose ends from previous work:
left todos:
snap install --unaliased- snap install --prefer
- deprecate
aliasesinsnap.yaml
1 Like
That seems a bit of an unpleasant burden to impose on users. Is there not some reasonable way to auto-convert any existing manual aliases enabled by a user?
left todos (waiting for 2.26+ to be out for a little while):
- deprecate aliases in snap.yaml
- snap install --prefer
@sergiusens @kyrofa now that 2.27 is out following 2.26 that actually introduced the change for the approach to aliases to stable is probably time to start deprecating ‘aliases’ in snapcraft.yaml itself,
let me know if I need to create a bug/issue or something else
Just deprecate? Should probably also raise a warning in the review tools
I can do that. This will cause auto-reviews to fail so I wonder if we should wait for snapcraft to complain about it for a while. We can provide a descriptive message and optionally a URL for the review tools warning so people know how to fix from the warning alone, perhaps that is enough?
yes, my idea was to first start with snapcraft deprecation
1 Like
FYI, the review-tools have been updated to show a deprecation message, but currently at ‘info’ level which won’t block automated reviews. When the time is right, we can change this from ‘info’ to ‘warn’.
@pedronis - is the time right to adjust the review tools to trigger manual review if specifying v1 aliases?
Was that ever done? Yes, we should definitely be blocking old aliases by now.
No, it wasn’t because I didn’t get an answer. You gave it, so I’ll update the tools accordingly.
What’s the status of support in different distributions now? I have been maintaining old-style aliases in snapcraft.yaml because the last time I looked, distros other than Ubuntu were on older snapd versions that didn’t support the store aliases.