Why not attach build binaries to the releases?

[ThioJoe]

I tried downloading the 0.39 release's build from the GitHub actions here, but they say "expired" (apparently the limit is 90 days)

Considering releases are only like twice a year and the Action builds them automatically, why not just download and attach them to the release posts?

Sure I could download the latest nightly build, but I'd prefer the stable release. And sure I could go with one of the other build repos linked, but I strongly prefer first party for security purposes.

[llyyr]

mpv doesn't provide binaries, the ci builds are purely for testing purposes and may or may not be missing optional dependencies required for features you'd expect out of a video player. Build it yourself

[ThioJoe]

Ok well they could still be attached to the releases for testing purposes. I'm using the automatic build from the latest commit and it's fine.

They're already being created automatically, so it's a trivial amount of effort to just attach the occasional release builds to their release posts instead of relying on the links that expire from the Action.

[Keith94]

Agree with that. As a workaround you can use videohelp.com or softpedia.com for stable releases

https://www.videohelp.com/software/mpv-media-player/old-versions

[hooke007]

Agree with that. As a workaround you can use videohelp.com or softpedia.com for stable releases

It's the copyback of shin's build. https://sourceforge.net/projects/mpv-player-windows/files/release/
Which is also listed in the mpv.io

[avih]

It's the copyback of shin's build

Yes, but it's still not a CI build.

FWIW, I agree with the original request.

Keeping CI builds of release versions for posterity does have value. As noted, for testing/bisecting reasons, and sometimes it's just good enough for the user even without the additional features which third-party builds may have.

It also doesn't depend on individual third parties to maintain a public list of release builds.

It's true that the CI build features can change occasionally, which might make it harder to bisect, but the same goes for third party builds.

Overall, I think keeping CI artifacts of release versions would be useful.

IMO the only blocker is that someone needs to do it, and I don't know how much effort that would take to automate it (doing it manually is error prone and required invidually for each release, which is effort).

[mrfragger]

Yea I hope for point releases at least for Windows mpv-i686 32-bit, mingw32 64-bit, msvc 64-bit and Mac 13/14/15 starting with 0.40 upcoming release.

One reason it might not be good is there might be a influx of support requests. But those users will never have heard of github or know what it is nor wanna get an account. I'm trying to get friends and others to use mpv with uosc and a config file the trust factor of installing all these things is a leap of faith (brew Mac, scoop Windows, Linux already aware) so if they can download mpv binaries from the official site that's one less thing to convince someone new to mpv that it's from a legit source.

[monarc99]

Whoever wants to offer fully compiled versions of mpv must also provide support for them. And not only support, someone also has to make sure that security holes are not spread permanently. Since the functionality of mpv depends on a large number of libraries, an “official” version of mpv will only be compiled with a minimal number of libraries. This means that it may lack functionality that a non-experienced user would expect.

In general, I don't think compiled versions are a good idea.

[ThioJoe]

Whoever wants to offer fully compiled versions of mpv must also provide support for them.

Says who?

In general, I don't think compiled versions are a good idea.

They are literally already being created automatically by the action - I just am suggesting to attach the ones for releases to the release post 😭