Perhaps you can create a separate repo for downloads? You don't have to bloat your main repo that way.
That's awkward and unintuitive. One of the great things about the Downloads tab is it's the obvious place to go if you want to see any previous releases. Using a separate repo solves the bloat issue, but means I need to have a dedicated section of my README saying "if you want to see past releases go to [this repo](...)". Not to mention this now bloats my on repo listing on GitHub unnecessarily, making it harder to find my legitimate projects.
Basically, it's a lot more work just to get a worse result. Previously, GitHub was a one-stop shop for simple open source projects. Now, it's not. It's that simple.
> Previously, GitHub was a one-stop shop for simple open source projects.
It still is. The key words there being "open source." When you go to GitHub, you expect to see the source. Only when the project is distributed as source, like Python/Ruby projects or Twitter Bootstrap, should you expect to be able to download something meant for an end user.
And you seem to be making a bad assumption about why an open source project might want to host downloads as well. Maybe you should check out my github profile? I have a handful of Safari extensions on there. They're open-source projects. But in order to actually install it into Safari, you need to have a Safari developer certificate (free, but still takes effort to acquire), load up the project in Safari's Extension Builder, and install it that way. It would be ridiculous of me to require people to do that just to use my extension, so I build the extension and upload the build product to my github project. This way anyone can download the built product and try it out (which is really just a codesigned xar archive of the project with a fancy extension). Meanwhile, the source is still open for all to see on the project.
Edit: I just remembered my HN name isn't my github name. https://github.com/kballard
The only real alternative I have now is to store the packaged extensions in the repository itself and use tags to point to the blobs, and hope that this works effectively. Even if it does, this is going to bloat the size of my repository for no good reason.