Goodbye, Uploads(github.com)
github.com
Goodbye, Uploads
https://github.com/blog/1302-goodbye-uploads
107 comments
You're always welcome to host your downloads on SourceForge, even if your project is hosted elsewhere.
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.
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.
Using any branch will balloon the size of the repository. It's much better to use something like S3.
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.
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.
> 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.
You'd be amazed how even small zip files can quickly make a repo an unruly monster. Tread carefully if you take that route.
Huh, I never knew these existed. Did any major projects on github use this feature?
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
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
At least for tornado, it can be entirely replaced by: https://github.com/facebook/tornado/tags. Each tag automatically generates a zip/tarball.
The HTML5Boilerplate.com project has a big fat button on their site that is a link to a download on their GitHub repo.
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.
ES have debs on their website
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.
Which link to github downloads? :)
http://www.elasticsearch.org/download/2012/12/07/0.20.1.html
http://www.elasticsearch.org/download/2012/12/07/0.20.1.html
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&sort=created&direction=desc&state=closed&page=1">issues</a>
</h2>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"
http://www.elasticsearch.org/guide/reference/modules/plugins...
"The ability to install plugins from github allows to easily install site plugins hosted there"
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.
Bad for me as now I have to find another service to store my project binaries and (likely) add to my monthly bills.
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
It should be noted that they are leaving the existing uploaded files available.
I knew that but I didn't think I needed to say that, but it can't hurt. :)
It still leaves some prominent open source projects, including ElasticSearch, with extra work that they need to do for their next release.
It still leaves some prominent open source projects, including ElasticSearch, with extra work that they need to do for their next release.
True enough. Certainly a hassle for the people who used it.
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.
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.
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.
Don't do that. After a while it really adds up and slows down cloning times.
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.
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.
Any time a feature is removed you are going to get people whining, no matter how small the feature.
Or each repo might have a corresponding repo where only binaries are pushed, and probably the raw link might be used as a workaround.
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.
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.
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)?
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)?
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.
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.
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.
> 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... :] )....
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... :] )....
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.
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.
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.
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.
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...
Because it would make for a terribly annoying history to be adding a build artifact along with every commit (and repo bloat)
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.
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.
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.
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.
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.
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.
These are my exact sentiments. While I can sympathise with those who run their project websites off of Github and used the downloads feature having a compiled downloadable file alongside the source to me feels out of scope for what Github is. To me this change is exactly that: Github focusing on their core strength: source control hosting.
As far as I can see "compiled downloadable files" are not really what most people use downloads for.
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).
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).
So distribute the files using the github pages feature.
>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.
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.
[deleted]
Bootstrap can be distributed as source. Just download at the last stable tag.
But that isn't true of many other legit open source projects. As others have pointed out: mobile apps, browser extensions, native apps / libraries, etc. are much more readily accessible when distributed as binaries than as source. Most open-source projects don't want to require everyone to learn how to build from source before they're allowed to use the project, and I think that's a good thing.
One other note: last I checked, the auto-generated ZIP/TAR downloads (for tags or master) were completely broken for any repo that uses submodules.
Not everything is distributed as source.
Eg. Android app - source in git repo, apk in download, what's wrong with that?
Eg. Android app - source in git repo, apk in download, what's wrong with that?
Or every JavaScript library that has a .min build
you should
you should be getting it from the official website
> 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)
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)
What if the project needs to be compiled?
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.
The author or vendor should be supplying a compiled binary for download in my opinion somewhere else like their website or even via Bittorrent.
For a lot of projects the gh-pages 'is' the official website. Smaller projects have never (until now) needed another location to host a full project, you may disagree that github aims to be a place to host open source projects but gh-pages, a hosted wiki and issue tracker suggests otherwise.
I don't know about this stuff, so ask in earnest: couldn't such smaller projects upload their compiled installers to some free app hosting service, and link to that from their github site pages?
They can, but it means dealing with another service which is inconvenient, especially for OSS projects
[deleted]
But Github has been moving more and more to be the site for a project, that's what Github Pages is explicitly for. It was nice to have everything under one place, with one account system. Not unrecoverable, but to me this was a regrettable decision for them to make.
And who's going to pay for my bandwidth?
Maybe the change is to combat those who have been leeching off of Github for free bandwidth. If you're serious about your project and you're consuming enough bandwidth to worry about a big S3 bill, you're probably big enough to be able to afford to pay for bandwidth. S3 is cheap and dead easy to use.
How is using a service that Github provided "leeching"? Is hosting an open source project there also leeching?
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.
> 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
Good thing you speak for every repo
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-
+1++1 Exactly...
This is what I have been trying to communicate.
This is what I have been trying to communicate.
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.
(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.
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...
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...
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?
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
Nice catch. Fixed!
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.
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.
There's no misunderstanding here. You're removing a feature which a lot of us use and pay for. This sucks.
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.
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.
The downloads aren't stored in git. They're stored on Amazon S3. Every download link redirects to cloud.github.com, which is fronted by Amazon CloudFront.
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?
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?
Ah my fault then I misunderstood the blog post. Sounds like they are just removing it to alleviate confusion only then as the blog post states.
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.
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.
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.
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.
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.
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.
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
Edit: I just remembered my HN name isn't my github name. https://github.com/kballard
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.
I'll shoot myself before adding binaries to source control.
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...
Ugly and more annoying, but at least the files are somewhere...
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.
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.
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.
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.
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.
For a lot of us, the GitHub page was the project homepage. Now we're going to be forced elsewhere, like BitBucket.
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.
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.
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 ...
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 ...
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.
>>> 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.
Well said. I think we might see some open source projects go back to self-hosting.
> 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.
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.
>> 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.
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.
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.
BitBucket still supports uploads.
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?
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?
I'd be worried about Github reinstating this feature and your solution becoming redundant.
I think it's an even better opportunity for the indieweb folks to show that their arguments apply even to git hosting.
Surely the paired announcements make it obvious? uuencode your binaries (okay, okay, base64, and get off my lawn) and put them in a gist.
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 :(
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 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.
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.
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
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
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.
I do believe using Dropbox for distro is against their TOS.
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
[1]: http://projecthawkthorne.com