Earlier quoted context omitted.
I mostly care if projects don't accept bugfixes. For example "inotify feature longer works with the latest glibc release due to subtle API change" might be an easy 10 line pull request to fix. But if the maintainer doesn't take the pull request and make a release, then the effort of fixing it is wasted, and every single user has to workaround/suffer from that bug into the future. There are loads of projects in that s…
I wish github and other code hosters made it easier to "just make a release". Next to the "Download zip" button on github, they should add a "Download built .deb" and "Download built .exe" - and those buttons should work on any fork, branch, PR, etc. And they should add all the necessary build infrastructure to achieve that. It turns out that at scale, build infrastructure is pretty cheap to run, since caching is so…
My point is, there is no way github could add a fully automatic "build and package this release" button. It would require tons of configuration (and trial and error...) from the user.
But good news! If you _are_ willing to figure out how, you can make a github pipeline that compiles and packages your code (producing an "artifact"). Several projects I follow do exactly this. A complex problem like this essentially requires a bespoke solution, and to be fair github does give you tools to automate said solution. The problem is not the infrastructure but the complexity of build systems.
I do agree there should be more ready-made pipelines to aid this process. When I tried to release a python program to work on linux, windows, and macOS, I quickly realized I wasn't interested in figuring out how to make a working pipeline (after spending a weekend getting it to build on each OS in the first place). But surely that's because python is particularly bad at package management... Well, most languages are particularly bad at it