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