Goodbye, Uploads

https://github.com/blog/1302-goodbye-uploads

by aidanskinner • 14 years ago

106 104 14 years ago

daleharvey7• 14 years ago

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.

technoweenie2• 14 years ago

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

daleharvey7• 14 years ago

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.

cypherpunks01• 14 years ago

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

insteadof• 14 years ago

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

fbuilesv2• 14 years ago

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.

vulf3• 14 years ago

That's using the zips github generates for every repo, not the downloads section of the repo.

wooster5• 14 years ago

Sure, here's a few:

https://github.com/facebook/tornado/downloads

https://github.com/lloyd/yajl/downloads

https://github.com/adobe/brackets/downloads

https://github.com/textmate/textmate/downloads

https://github.com/KentBeck/junit/downloads

https://github.com/github/hubot/downloads

stock_toaster3• 14 years ago

At least for tornado, it can be entirely replaced by: https://github.com/facebook/tornado/tags. Each tag automatically generates a zip/tarball.

akoumjian• 14 years ago

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• 14 years ago

ES have debs on their website

bjg• 14 years ago

Which link to github downloads? :)

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

nieve• 14 years ago

The debs on the Elasticsearch site are links to Github downloads: http://www.elasticsearch.org/download/2012/12/07/0.20.1.html links to https://github.com/downloads/elasticsearch/elasticsearch/ela.... If you don't have a reflex to check the destination of a link to a binary you might not notice it that much, but I see a decent number of projects hosting their release builds on github. It's certainly common for APKs as was pointed out above, but I've seen it for Adium plugins, debs & rpms, even full apps - if memory serves the precompiled SSHuttle gui for OS X was hosted on github as well as the code.

donretag• 14 years ago

Plugins are managed (quite nicely) via GitHub downloads. This includes official and third-party plugins. The official plugins can migrate elsewhere, but it will be difficult for the third-party plugins.

http://www.elasticsearch.org/guide/reference/modules/plugins...

"The ability to install plugins from github allows to easily install site plugins hosted there"

mifrai2• 14 years ago

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.

fbuilesv2• 14 years ago

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.

i386• 14 years ago

Don't do that. After a while it really adds up and slows down cloning times.

ludwigvan• 14 years ago

Or each repo might have a corresponding repo where only binaries are pushed, and probably the raw link might be used as a workaround.

mifrai2• 14 years ago

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.

benatkin4• 14 years ago

You also need to do it right away, as they are shutting off uploads today. This isn't just deprecation, but immediate removal of a feature. If it were just deprecation, it would stay up to give people time to change their practices. http://en.wikipedia.org/wiki/Deprecation

stock_toaster3• 14 years ago

It should be noted that they are leaving the existing uploaded files available.

zbowling• 14 years ago

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• 14 years ago

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)?

ceol5• 14 years ago

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.

DigitalSea5• 14 years ago

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.

jakebasile3• 14 years ago

What if the project needs to be compiled?

DigitalSea5• 14 years ago

Then I would imagine the official site would have a downloadable binary already compiled. Github isn't really a place for getting compiled binaries, it's for collaboration and source control. I've never gone to a repository with the intent of being able to download compiled anything, chances are if you're apt enough getting to the repository you'd already know to expect this.

The author or vendor should be supplying a compiled binary for download in my opinion somewhere else like their website or even via Bittorrent.

imrehg• 14 years ago

Not everything is distributed as source.

Eg. Android app - source in git repo, apk in download, what's wrong with that?

daleharvey7• 14 years ago

Or every JavaScript library that has a .min build

snogglethorpe5• 14 years ago

> 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• 14 years ago

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.

tedivm• 14 years ago

So distribute the files using the github pages feature.

detst• 14 years ago

  you should

Why do people feel the need to tell others what they should or shouldn't be doing when there clearly isn't a right or wrong way? Some people found it useful, GitHub decided to discontinue the feature but your opinion on what others should be doing isn't relevant. It's certainly closer to their core feature set than web site hosting and I don't anticipate that going away anytime soon.

  you should be getting it from the official website

Oh, so from our GitHub hosted sites?

buttscicles• 14 years ago

>If you need a compiled binary, you should be getting it from the official website

Many projects use Github pages as the official website, Twitter Bootstrap for example. What should they be expected to do? Distribute via BitTorrent and hope everybody that wants to use the project has a torrent client installed (and are able to even use bittorrent at their place of work/school)? It's just not as convenient for maintainers or users, who just want to grab an archive and get on with it.

ceol5• 14 years ago

Bootstrap can be distributed as source. Just download at the last stable tag.

clobber• 14 years ago

> I can't really think of any instance where I've seen downloads used in a Github repository in a very long time

Good thing you speak for every repo

gurkendoktor• 14 years ago

> I can't really think of any instance where I've seen downloads used in a Github repository in a very long time

Because, from painful experience, programmatically uploading files has been broken often enough.

> considering Github is all about collaboration and source control not a file hosting service

Except that github is offering websites which are great to present small projects - should it cut off these too? (I now believe: yes)

X-Istence2• 14 years ago

GitX, one of the many Git gui frontends for Mac OS X is distributed using the Download mechanism. It allows me, the user to easily download a pre-compiled binary instead of having to download and then build it.

cnlwsu• 14 years ago

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-

Surio5• 14 years ago

+1++1 Exactly...

This is what I have been trying to communicate.

keithwinstein• 14 years ago

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• 14 years ago

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

rachelbythebay• 14 years ago

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?

cheeaun• 14 years ago

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• 14 years ago

Nice catch. Fixed!

jeremymcanally• 14 years ago

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.

wooster5• 14 years ago

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

res0nat0r3• 14 years ago

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.

snogglethorpe5• 14 years ago

No, most people commenting here seem to perfectly well understand what's going away. An auto-generated repo-contents tarball isn't the same thing as a proper source-distribution tarball.

wooster5• 14 years ago

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.

eridius3• 14 years ago

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• 14 years ago

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

eridius3• 14 years ago

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.

zalzane• 14 years ago

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.

snogglethorpe5• 14 years ago

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

kibwen• 14 years ago

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.

benatkin4• 14 years ago

Well said. I think we might see some open source projects go back to self-hosting.

ceol5• 14 years ago

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

Project wikis are obviously useful in building software. Pages are more for documentation/pitching, but the hosting space for some HTML and images is probably much lower than hosting multiple binaries per project.

tristanj• 14 years ago

To me, it looks like a cost issue. File hosting is not free and providing a downloads tab just encourages developers to use them as a filehost, sometimes as the sole one. Removing the tab is a subtle move to tell people to host their files elsewhere. GitHub probably doesn't want to end up like SourceForge, which provides project file hosting except with ads to support the hosting costs. Having advertisements to GitHub seems against the site's nature so by discontinuing the tab they're showing they don't intend on being a filehost anytime soon.

With that said, I would not be surprised if in the future if they reintroduced it as a "new" feature for their enterprise customers. We'll just have to wait a few years ...

Surio5• 14 years ago

Ads are a non-issue here. SO carries job ads, and so does github. " Kabam is hiring: Senior Software Engineer in San Francisco " can be seen on that blog post page. It's something else.

>>> File hosting is not free and providing a downloads tab just encourages developers to use them as a filehost, sometimes as the sole one

IMO, that should not be an issue either. For users (like myself) a binary is the only way to integrate a tool/app into existing workflow to test its efficacy first.

They are plain in the wrong wrong with this move. that's all.

kneath• 14 years ago

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.

wooster5• 14 years ago

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.

Surio5• 14 years ago

Sorry, but don't think you answered anything at all.

From my own experience and anecdata, software development workflow is not as clear cut as envisaged by github's definition of what constitutes "elegance" or "good solution", but by the constraints faced by the development teams and their internal working framework.

Here's the kicker in your reply, retaining the upload functionality (for images, which can be large in the MB size as well), but removing it just for binaries makes no sense to me.

Surio5• 14 years ago

>> As long as projects need to distribute software that is not code

and there will be many many.

>> a Github-only solution is inadequate

correct.

>> All I'm asking is for you to be honest, Github.

I read his reply, but no, he did not answer your points, in my view.

technoweenie2• 14 years ago

Product documentation (wikis) is a very important part of building software. GitHub Pages sure aren't, but they're viewed internally as an addon. There's very little mention of it in the UI.

bdcravens• 14 years ago

BitBucket still supports uploads.

KNoureen• 14 years ago

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• 14 years ago

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

benatkin4• 14 years ago

I think it's an even better opportunity for the indieweb folks to show that their arguments apply even to git hosting.

kps• 14 years ago

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

benrhughes• 14 years ago

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 :(

davvid• 14 years ago

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.

Surio5• 14 years ago

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

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

machrider• 14 years ago

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.

vulf3• 14 years ago

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

conroy• 14 years ago

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

rcbowen• 14 years ago

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

Goodbye, Uploads

Related Stories