Goodbye, Uploads
github.com
github.com
(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.
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...
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.
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.
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 ...
>>> 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.
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.
For a lot of us, the GitHub page was the project homepage. Now we're going to be forced elsewhere, like BitBucket.
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.
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.
This is what I have been trying to communicate.
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.
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.
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.
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.
Edit: I just remembered my HN name isn't my github name. https://github.com/kballard
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.
The author or vendor should be supplying a compiled binary for download in my opinion somewhere else like their website or even via Bittorrent.
Eg. Android app - source in git repo, apk in download, what's wrong with that?
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... :] )....
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.
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.
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.
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.
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.
More often, it's used for source distributions which just want to add a few tweaks to make things easier for downloaders (pre-generate a configure file, etc).
you should
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.
Good thing you speak for every repo
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)
http://www.elasticsearch.org/download/2012/12/07/0.20.1.html
<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&sort=created&direction=desc&state=closed&page=1">issues</a>
</h2>http://www.elasticsearch.org/guide/reference/modules/plugins...
"The ability to install plugins from github allows to easily install site plugins hosted there"
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 :(
I'll shoot myself before adding binaries to source control.
Ugly and more annoying, but at least the files are somewhere...
Bad for me as now I have to find another service to store my project binaries and (likely) add to my monthly bills.
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.
It still leaves some prominent open source projects, including ElasticSearch, with extra work that they need to do for their next release.
Anecdotally, I was always surprised when I ran across it being used, as it was a relatively infrequent occurrence. It seemed to always work well though, when I did. I was even tempted to use it for a few projects. Guess I will have to seek other avenues. Be it s3, dropbox, cloudapp, droplr, or something else.
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.
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.
You'd be amazed how even small zip files can quickly make a repo an unruly monster. Tread carefully if you take that route.
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.
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)?
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.
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
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?
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.
Which, conveniently enough, is exactly what they want us to do ourselves now. I already pay GitHub to do that for me, how is it a benefit for me, the paying customer, to do that myself by hand?