I was a vocal critic when GitHub discontinued their downloads product earlier this year. I work on open source projects with compiled binaries. GitHub's answer to distribution had been "Use S3" which I never found satisfactory.
As soon as they release an API, I'll be migrating all my projects over.
Which makes me wonder, since that wasn't all that long ago, why did they not give a teaser? Or did they, and we all missed it?
Discontinuing the downloads was a big deal to a lot of people, which generated a non-trivial amount of bad press, but if they'd simply said "we have something better in the works" then I don't think anyone would've cared. Surely this wasn't dreamt up in between then and now...?
Still, why would you get rid of it in the first place just because something is better on the way? IIRC their reasons for getting rid of it had to do with not being a distribution center and focusing strictly on the source code development. It probably wasn't just "dreamt up" but more likely they found new reasons why it should complement their future business model.
We thought the Downloads feature was doing more harm than good in its previous form. Quality-wise it just wasn't up to snuff (failed frequently, flash, lack of design). Bad experiences on the site need to be fixed or killed. No one was willing to dedicate time to fixing it because they felt their time was better spent on other things so that left killing it.
The timing of the Releases feature only entered into the decision a little bit. It's hard to tell when something is going to ship at GitHub because there's no deadlines. Projects are done when they're done. The downside to this approach is that you can't rely on ship dates when making decisions like when to kill a feature something might replace.
But you didn't just kill a feature, you also killed data with it!
Gladly I am not affected, I have not recently tried to download an abandoned binary for a project hosted on github and it was deleted without replacement, but I still feel sad about what might now be lost
Having the download buttons listed like that baffles me. Many downloads have similar names, and having them in a vertical list is far easier for determining which one you're supposed to get.
I just had a glimpse of a wonderful future where GitHub releases a payments system, packaging options, and suddenly becomes an ideal app store ecosystem.
With their recent $100mm round, they might be working on this already. Could lead to an interesting future of software selling/piracy, where those that will buy, buy, and those that are desperate not to can
Cyberduck, an FTP client, takes a similar (though easier) approach. You can buy it on the Mac App Store for $23.99 [0], get precompiled binaries for free on their website [1], or grab the source yourself [2].
Not sure why he/she deleted their post, but for an excellent in-depth analysis of App Store pricing I thoroughly recommend Michael Jurewitz' 5 part blog post "Understanding App Store Pricing"
Theres a bit of Economics 101, and some very well explained real world data on app pricing. Essentially Michael's advice boils down to: try doubling your price. If you lose less than half your sales, you're now making more money than you were before.
I wish I could pay for Blink on Windows, because it's my main SIP client. Windows definitely doesn't get the attention that Mac OS does, but the client is the best one I've found. (I really grew to hate Bria/X-Lite.)
This can't really work on the long run / at scale, ya know... Someday someone will make a script that does the equivalent of the above, then somebody will make an alternative app-store GUI that leverages that script to get anything that's open-source for free. And you can't really sell as SaaS <$10 "apps" - so in the end you have two options: (a) classic closed source and (b) pay for subscription / user account (ok, there are the adds/in-app-purchases financed ones and they could profit from the "paid open source model").
Couple this with amerine's suggestion to allow release packages from private repos, and developers could also use GitHub to sell closed-source software.
I blogged a bit about this, with discovery and an app store type area with 3rd party apps like my site could be of use and extend features beyond what GitHub wants to support.
If you want to read about my ideas: http://derekmyers.com/posts/open-source-information-overload...
This, along with a separate/editable changelog (hidden commit log.) Some people manage a separate private repo, code review things over a period of weeks there, and then make a "release" by doing a single commit to the public repo with the final changes, minus any private keys/strings/etc.
While on the subject: does anyone know a software/service for automating software releases?
I usually perform these steps manually:
create a new tag, merge the “next” branch into the “master” branch, run “make dist” from a clean checkout, do a handful of sanity checks on the result, gpg-sign it, push it into a separate git repository for the website, archive the current docs in the website, update the website’s docs with the new docs, send posts to a mailing list, twitter, google+, update the changelog with a placeholder for the new version.
I realize not 100% of that is reasonably automatable, but is there anything which tries to tackle this problem?
By the time you would work out how to automate this process in some tool so it adapts to your requirements, you could write your own build script doing exactly all that.
Factor.io might be a good fit for you. I am the co-founder/CEO and I hate self promoting, but in this case I think that we can help. We provide a way for you to create workflows like the one you described. It's kind of like IFTTT/Zapier for Dev/DevOps. But we support running numerous actions, custom code for new extensions, and more complex operations. Still in private beta, but would love to help out and get you to test it out. Shoot me an email maciej@factor.io.
That's actually what I set out to solve with jspkg.com, at least for JavaScript and CSS based projects. I'd say I've gotten to about 20% done toward that goal. Currently the site allows you to select a git tag from your repo and it will automatically package it up for you and keep track of downloads, archive old releases, etc.
Yes, but that normally involves lots of inline-shell-scripting and connecting a wide array of plugins together. It's not exactly a stream-lined process.
I use the release plugin myself on almost all my projects, but--BUT--it needs to be said that it's not very flexible. If you can't live with the way it's setup to do things, you're better off writing a shell script to automate things your way than trying to bend the release plugin to fit your needs.
That was my first thought when I saw this. It seems even more strange they discontinued it only to revive it with changes they could have just iterated through with new features/changes like this release.
Is there any way to add the release notes via a git commit? This is very nice, but it introduces further dependence on GitHub if something like that isn't possible. I suppose as long as there's API access someone could / will write an exporter, though. Anyway, great stuff either way!
The article claims that releases are structured around git tags. A git tag can be accompanied by a message which is shown on the releases page. In that sense, it doesn't depend on Github.
I'm not sure it's using tag annotations; I'm not seeing evidence of them. Plus, if I clone a repo with releases, then push (with tags) to a new repo, the new repo doesn't have any of the release notes.
Weird. I'm seeing some evidence of my tag annotations, but the first parts are cut off and I don't see a way to view all of them. Maybe they are still getting the kinks worked out...
Hmm. I created a dummy package and allowed GitHub to create the tag for the release. It looks like it used a lightweight tag, and I don't see any evidence of any extra refs:
$ git ls-remote https://github.com/dlitz/dummy
23ed6e532fb4a3eb1403e0091885ccdb9f09b577 HEAD
23ed6e532fb4a3eb1403e0091885ccdb9f09b577 refs/heads/master
23ed6e532fb4a3eb1403e0091885ccdb9f09b577 refs/tags/v0.0
Pull requests, on the other hand, are stored as refs in the remote git repo:
You should probably commit your release notes as a file in the repository before tagging the release, then just copy-paste them into the github "release" - that way anyone who gets the source tarball from anywhere also gets the release notes.
Something like this was missing since they removed the uploads [1].
Basically a release bundle may not be exactly the same stuff you have in your source code repository. You may need to generate documentation, configure files, run setup.py sdist or whatever, so a release may not be exactly a snapshot of your git repo.
So this is perfect. Great feature GitHub, thanks!
It would be nice that tags != releases though, because I can think of scenarios where you may add a tag that is not meant to be a release (ie. security update, you may want to tag the commit with a CVE).
Also it would be great if you could just link or display the changelog, CHANGES or NEWS instead of writing a text describing the release. That's for projects that already have a release procedure, but for the rest this is HUGE change because GitHub just improved their project management! I love it!
For JavaScript or CSS single-file projects it's actually quite simpler to wget the one file from the Raw URL (or copy-paste the contents into a new buffer in your editor), than to clone/download the archive and then move the file from the downloaded directory and then clean up the other downloaded files.
I see a problem with the current implementation: Releases are auto-generated from git tags. That means all tags you'll ever use on your repo will be auto-exposed as "release", even if the tag reads "dead_end_implementing_foo" or "before_major_rewrite".
Tags are an implementors' tool, releases belong to product management. I want to be able to control my releases, so at least be able to delete auto-generated ones (without losing the git tag).
It requires Adobe Flash to upload and since I have blocked plugins by default, even if I enable the plugin after loading the page (through Firefox's click to play), it doesn't work.
GitHub, please:
1. don't make Adobe Flash necessary.
2. allow me to select a file through browser's File dialog. I don't like drag and drop.
Interesting that they launch this without API access and without adding it to the right hand nav. Sure, it's above your repo but I don't think that catches the eye enough and this is definitely meant to be a primary item users will be searching for.
What a great step for Github. I was impressed with Pages, and now they're providing what SourceForge granted the public with for so many years. Options for everyone. All without the sponsored hosting!
As soon as they release an API, I'll be migrating all my projects over.
EDIT: Just added my first release. Super easy. https://github.com/hawkthorne/tmx2lua/releases