#Winget package broken
1 messages · Page 1 of 1 (latest)
damn that's ancient
That's an old build that's no longer supported, you can try opening an issue on the WinGet repo requesting that they update to v2.4.62.
i did one better https://github.com/files-community/Files/issues/12099
wait hold up
@lunar pelican We don't need to continuously update WinGet because the app will auto update. The issue in this case was that I forgot it was being used by WinGet and I removed the old version from the endpoint.
well yeah but why add that extra layer of indirection
Unless we keep old packages around forever, users will see old versions on WinGet and wonder why they don't install.
I'd rather have one good package that always works
the exe installer downloads the latest version at runtime, right?
we can, but the version info will be broken if it isn't updated manually
not necessarily, you're in control of that
i think?
yeah
although i'm a bit confused about 'one version per pr', does that mean removal and addition must be separate? in any case it's probably fine to host at most two versions at a time
yep, that does appear to be the case
It means you have to open separate PRs
fine with being broken or fine with updating manually
With the version number being wrong
But honestly, it's probably better to just leave an old version around and rely on auto update
auto update won't trigger for at least 8 hours after install right
or does files have a special ui telling you to update
It'll trigger as soon as the app is opened the first time
that works
There is a toolbar button
cool
lmao this is actually a bit of a regression because the previously free store version automatically showed up
I think this brings us back to the first solution to update the package to v2.4.62 and just rely on auto update.
mhm