
Goodbye, Uploads - aidanskinner
https://github.com/blog/1302-goodbye-uploads
======
keithwinstein
Kind of a pain for us (<http://mosh.mit.edu>). We have some distro watchfiles
that look at this location, and we'll have to get them to switch to whatever
new location we move to.

(Ironically a few weeks ago GitHub made an unrelated change to their URL
scheme that broke all the Debian watchfiles, including ours, that look for new
tags.)

Some advance notice would probably have been helpful, instead of immediately
killing this off. On the other hand, it's not like we're paying them to host
our project.

Like most Unix software projects, we do want to prepare binary .tar.gzs of the
Mosh releases, which have a ./configure and don't require autotools (unlike
the repository, which is for maintainers and requires autotools to build). We
wouldn't want to use a tag download of a .tgz as our authoritative release
because there's no reason to think the sha256 will be stable.

~~~
Niten
Yeah I'm surprised to see them essentially drop support for this common
workflow... downloading auto-tarballed tagged SCM commits is insufficient for
Autotools projects, or other situations where you need to do pre-processing on
your source code with (potentially fragile / version sensitive) tools which
you don't want to require your end users to have installed.

It's not like inexpensive file hosting is difficult to come by these days,
thankfully. And it's probably better for one's main distribution site to be on
a domain under one's own control, anyway. But it was more convenient to be
able to just put it up on GitHub, and somewhat more inspiring of confidence in
the source archive's integrity.

I wonder how much this feature was costing them, anyway? And whether they'll
lose out in any significant way when links to projects' canonical release
archives point away from GitHub...

------
kibwen
I'm getting mixed signals from Github. Are they or are they not trying to be a
one-stop-shop for project hosting?

As long as projects need to distribute software that is _not_ code, there will
be projects for whom a Github-only solution is inadequate. This opens the door
to competitors who are willing to offer "Github, plus that one feature that
you really need but that Github doesn't think that you do".

 _"[...] part of our ongoing effort to keep GitHub focused on building
software [...]"_

So I suppose that Github Pages and project wikis will soon be gone as well?

All I'm asking is for you to be honest, Github. Just come out and say that the
feature was a pain in the ass to support and a looming legal liability.

~~~
kneath
Honest answer: Because I want to focus on distributing software rather than a
generic "one size fits all" (no one) upload anything model. It wasn't a good
solution. S3 is a better solution.

Uploads may be going away, but the functionality behind it is being focused in
a more usable, elegant way. Case in point: image attachments (the primary use
for our uploads section until Friday). Which has all of the legal and support
ramifications of the old Uploads section.

~~~
wooster
It was a great solution for those of us who used it. It was also backed by S3
and Amazon CloudFront (as far as I can tell), and was integrated into the
site, rather than being forced onto a wiki page or some such.

For a lot of us, the GitHub page _was_ the project homepage. Now we're going
to be forced elsewhere, like BitBucket.

------
cnlwsu
I am actually pretty sad about this. Installers (deb, exe, etc) and libraries
can sometimes be hard to build and require a difficult to setup environment.
Its easy to sit there from a throne built on blog apps and twitter clones and
say "they should make it better" but sometimes complex systems with large
teams are difficult. Having them as your dependancies is made a little easier
when you can just grab an installer that has been built with the proper
version of -blank-esoteric-dependancy-or-build-tool-

~~~
Surio
+1++1 Exactly...

This is what I have been trying to communicate.

------
wooster
This really sucks.

I've been using the downloads page to distribute binaries and/or source
distributions of a few packages, as it was a logical and easy place to do so.

For example, my biplist Python package has the versions available here:

<https://github.com/wooster/biplist/downloads>

Which are listed in the relevant pages on PyPI:

<http://pypi.python.org/pypi/biplist>

Now I'll have to migrate all of these over to some other location. Where? Who
knows. Maybe BitBucket.

------
eridius
I'm really sorry to hear this. The ability to host arbitrary project-related
files was extremely useful. For example, all of my Safari extensions host the
packaged version of the extension right on GitHub and link to the latest
version in the README, thus allowing for one-click installation of my Safari
extensions by anyone who goes to the page.

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.

~~~
timdorr
Perhaps you can create a separate repo for downloads? You don't have to bloat
your main repo that way.

~~~
eridius
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.

~~~
ceol
_> 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.

~~~
eridius
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>

------
DigitalSea
I'm sure some people will find a way to complain about this, but this is a
welcome removal. I can't really think of any instance where I've seen
downloads used in a Github repository in a very long time, especially
considering you can generate a ZIP file of any repository by doing this to the
end of the repository URL: /archive/master.zip the downloads functionality has
always felt redundant anyway.

If you need a compiled binary, you should be getting it from the official
website or Bittorrent not expecting it to be up on Github already compiled
considering Github is all about collaboration and source control not a file
hosting service.

Two changes in one day, Github are nailing it.

~~~
snogglethorpe
> _this is a welcome removal_

No, it's not "welcome", because separate "downloads" are (1) no burden on
people who don't use them, and (2) actually a useful feature.

In many cases, a tarball of the repo contents _isn't the same thing_ as a
distribution tarball, because the latter often contains various generated
files that may be more annoying for the user to generate than is justified for
somebody just interested in compiling and installing the software. Making a
distribution tarball typically involves generating those things and packaging
them together with the sources.

Some repos contains generated files as well to work around the issue, but this
is ugly and causes its own problems.

> _Github are nailing it_

Er, removing useful features may be good from a business point of view (github
may feel the support burden, etc, isn't justified by the usefulness), but I
don't think it deserves to be called "nailing it" (unless "it" is the user, of
course... :] )....

~~~
lelandbatey
I feel like GitHub should not be the place where you host your distribution
tarball. As was mentioned, GitHub is about source code and collaboration and
the distribution of that source code.

It's just not inside the scope of what GitHub does, and in that sense I think
this is an improvement because it makes for a more focused product.

~~~
snogglethorpe
Maybe github doesn't want that, but it's _very_ common practice for
small/simple projects to have only a github presence, and no dedicated website
of their own at all. It's simple, easy, and keeps everything in one place.

Again, this change may very well be in github's interests, but it's also going
to make life more annoying for many gibhut users.

~~~
chii
why can't those projects simply host the downloads in the actual repository?
its just a binary file, and the link to the raw file can be generated quite
easily. For example: [https://github.com/joelgwebber/xna-
platformer/raw/master/pla...](https://github.com/joelgwebber/xna-
platformer/raw/master/platformer/Microsoft%20Permissive%20License.rtf)

~~~
daleharvey
Because it would make for a terribly annoying history to be adding a build
artifact along with every commit (and repo bloat)

~~~
ceol
Then why not in a separate repo specifically made for hosting your compiled
software? Or only include a build for stable releases?

It's a hack, sure, but it's necessary if those small projects don't want to
put up an official site or host on S3.

~~~
DigitalSea
I think what it comes down too here is that most developers are too cheap to
pay for their own hosting and expect Github to provide free bandwidth and
storage space for their compiled binaries and preconfigured projects. Github
is a company at the end of the day and getting rid of the downloads API will
probably save them a lot of money by kicking off the leeches who've been
abusing and taking advantage of Github's storage and bandwidth generosity for
far too long.

It literally costs cents for S3 and they offer a 1 year free usage tier for
new signups. S3 or proper hosting is definitely the way to go.

~~~
daleharvey
Thats unfounded, patronising and plain rude.

For one it may amaze you, but some people actually pay for Github. Those same
developers often have their own hosting (I personally have 3 linode vps's
active for various projects)

The fact is it was just simpler as the maintainer of an Open Source project
with numerous contributors to host it under one roof, all the contributors
have their access granted in a single place, one set of keys to set up, one
account to manage personally, and a single place to go look for X.

I am sure you love github and all, but I assure you you arent helping them by
before anyone had even mentioned a word, insulting everyone who dared to voice
an opposing opinion to this change, then continuing to do so in follow up
comments.

------
cheeaun
Wait, this will affect hubot (<https://github.com/github/hubot>) as well
right? The README tells people to download the latest version on
<https://github.com/github/hubot/downloads>

~~~
ben_straub
Nice catch. Fixed!

------
akoumjian
That's really too bad. We've been pulling elasticsearch's .deb files from the
downloads page on their github repository. Not everything is conveniently
installed from source.

~~~
aidanskinner
ES have debs on their website

~~~
bjg
Which link to github downloads? :)

<http://www.elasticsearch.org/download/2012/12/07/0.20.1.html>

~~~
X-Istence
These:

    
    
      <h2 class="download_link">
      0.20.1: <a href="https://github.com/downloads/elasticsearch/elasticsearch/elasticsearch-0.20.1.zip">zip</a>
      / <a href="https://github.com/downloads/elasticsearch/elasticsearch/elasticsearch-0.20.1.tar.gz">tar.gz</a>
      / <a href="https://github.com/downloads/elasticsearch/elasticsearch/elasticsearch-0.20.1.deb">deb</a>
      / <a href="https://github.com/elasticsearch/elasticsearch/issues?labels=v0.20.1&amp;sort=created&amp;direction=desc&amp;state=closed&amp;page=1">issues</a>
      </h2>

------
benrhughes
This is understandable, but a bit sucky for me. Since day 1 I've hosted
todotxt.net's installer files on github, and the project's landing page uses
the downloads API to link to the latest version.

Thankfully I changed the app to link to the landing page rather than the
downloads page.

In any case, it was nice while it lasted. Especially the ability to track the
number of downloads.

Guess I'm spending the night changing my release process and landing page :(

------
zalzane
So now how do I distribute dlls that are supposed to be used by my project?

I'll shoot myself before adding binaries to source control.

~~~
snogglethorpe
As someone noted, one possible workaround is to make a separate repo for just
the downloads. E.g., for project "blah", add a "blah-download" project, and
commit your "completel download" tarballs in there...

Ugly and more annoying, but at least the files are somewhere...

------
rachelbythebay
This seems like the sort of thing you'd do if you found out people were
abusing your service to host arbitrary files. Get rid of the ability to
directly upload and download things ad you force them to step up their game.
Who's going to maintain an actual repo for their warez, right?

------
conroy
As a developer of a downloadable desktop game [1], this change really hurts
me. I distribute binaries for OS X and Windows via Downloads. The entire build
and upload process is automated, and has been working great for the last six
months. Switching over to S3 is going to cost me quite a bit, and it going to
be difficult to justify for a open-source video game that will never make any
revenue.

[1]: <http://projecthawkthorne.com>

------
mifrai
Good for them on cutting bloat and focusing on what's important to them.

Bad for me as now I have to find another service to store my project binaries
and (likely) add to my monthly bills.

~~~
fbuilesv
If your binary files are not huge you can always add them directly to your
repo (they don't have a repo file size limit anymore). If we're talking about
multiple GB just go for S3, we're talking about cents per month.

~~~
mifrai
Yeah, I'll likely end up using S3. Or maybe even bitbucket.

But there's a very real and somewhat irrational negative emotional response
when going from free to not-free. Or alternatively, from included in private
costs to a paid for feature taken away.

~~~
res0nat0r
Any time a feature is removed you are going to get people whining, no matter
how small the feature.

------
daleharvey
This makes for perfect timing, I was just about to write some code to
autopublish the distribution files for my project.

Where is a good place to put the output of a build these days? I really hate
the idea of build artifacts in my repository cluttering every commit.

Push them to a downloads branch? its nice because it has versioning and can
match the masters tags etc, but gh-pages has taught me I really dont like
using branches as completely seperate repositories.

~~~
technoweenie
Using any branch will balloon the size of the repository. It's much better to
use something like S3.

~~~
daleharvey
The size isnt a particular worry, this is a JavaScript library that should be
producing small files.

s3 is another service to manage which is annoying, but it probably is the best
option.

It is a shame, I do appreciate Github needs to focus on what is important, but
this change stopped it from being a one stop shop for quite a few OS projects.

~~~
vulf
> should be producing small files

You'd be amazed how even small zip files can quickly make a repo an unruly
monster. Tread carefully if you take that route.

------
bdcravens
BitBucket still supports uploads.

------
cypherpunks01
Huh, I never knew these existed. Did any major projects on github use this
feature?

~~~
insteadof
The HTML5Boilerplate.com project has a big fat button on their site that is a
link to a download on their GitHub repo.

~~~
fbuilesv
They're not removing downloads, only the uploads that can't be generated from
the repo itself. You can still provide downloads that work just a a .zip of
the repo contents.

------
kps
Surely the paired announcements make it obvious? uuencode your binaries (okay,
okay, base64, and get off my lawn) and put them in a gist.

------
zbowling
Nothing really prevents you from checking in your downloads in to a github web
project though and hosting via that though (but probably not the fastest
solution).

This is kind of a relic feature back when people compared github to
SourceForge. Github is collaborative source code hosting (open or private
projects alike) and not really open source project hosting.

~~~
justinator
Well then, what about Gitub Pages?

So, with GitHub, I can use the fancy git tools, I've got bug reporting and
issue tracking, I can make a website about it, but I can't offer a download
that's not a snapshot of the repo (barring any silly workarounds)?

~~~
ceol
Pages are definitely a development tool. Most of the time, (when some lazy dev
isn't using it as their blog!) they contain useful documentation and
instructions for _other developers_.

------
davvid
I started using uploads because the tarball directory created by the "download
a tag" feature was IMO ugly.

It uses "$user-$repo-$tag-$SHA1" as the basename. Please let us configure this
(what if we don't like to see $user there?). The sha-1 is redundant and
annoying for packagers that want to write simple scripts, which is also solved
by making it configurable.

------
Surio
I have used plain binaries of some projects from time to time, a) to test the
waters, and b) integrate a small tool into my workflow with minimal effort and
disruption to my overall task at hand.

Like I said elsewhere, the fact that they are retaining upload functionality,
but only for images and not for binaries makes no sense to me.

Source only distributions? This is what happens more-or-less:

[https://plus.google.com/109834643338395014064/posts/4hMiZ3s4...](https://plus.google.com/109834643338395014064/posts/4hMiZ3s44f8)

Someone else raised the same concerns, so in the principle of DRY:
<http://news.ycombinator.com/item?id=4908007>

------
KNoureen
I see a lot of worrying and annoyed comments.

But this is an OPPORTUNITY for eager hackers to create an external solution to
GitHub for distributing project builds and related binaries.

Or am I wrong?

~~~
skeletonjelly
I'd be worried about Github reinstating this feature and your solution
becoming redundant.

------
rcbowen
You're always welcome to host your downloads on SourceForge, even if your
project is hosted elsewhere.

------
machrider
This has been a long thread, but I've only seen S3 mentioned as an
alternative. Is there anything else that makes sense for hosting open source
packages? I was considering Dropbox, but I think Dropbox download links look
sort of suspicious.

~~~
vulf
I do believe using Dropbox for distro is against their TOS.

------
jeremymcanally
By the way, downloads of source aren't going away (i.e., get a zip or tar
ball)! Just the "upload anything and make it available" feature. There seems
to be a little confusion about that.

~~~
wooster
There's no misunderstanding here. You're removing a feature which a lot of us
use and pay for. This sucks.

~~~
res0nat0r
GitHub is for source code hosting. Not tens to hundreds of MB binary hosting.
Put your binaries in s3 and link to them from your project if needed.

They probably determined the excess bloat and strain on their infrastructure
from git cloning huge binaries outweighed the benefits so they are removing
the feature.

~~~
darkarmani
If that is all it is for I might as well host my own git repos too.

