Releases – a workflow for shipping software to end users

conroy 13 years ago |

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.

EDIT: Just added my first release. Super easy. https://github.com/hawkthorne/tmx2lua/releases

k3n 13 years ago | |

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

rtomayko 13 years ago | | |

We don't talk about unshipped features as a rule. It's hard to do so in a way that doesn't imply promises or timeframes.

ics 13 years ago | | |

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.

rtomayko 13 years ago | | |

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.

atesti 13 years ago | | |

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

hrjet 13 years ago | | |

Huh? This one requires flash too AFAICT!

hrjet 13 years ago | | |

I sought and got clarification from Github. The Flash is only for copy-to-clipboard functionality. Not related to Releases.

mh- 13 years ago | |

likewise. I would have never been so negative on the discontinuing of downloads if they released this prior.

this looks really good.

fudged71 13 years ago | |

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.

ksec 13 years ago | | |

My thoughts exactly.

jmduke 13 years ago |

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.

cjbarber 13 years ago | |

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

  git clone
  make clean; make install

ejdyksen 13 years ago | | |

I've already seen a number of apps in the Mac App Store that take this exact approach.

Two examples off the top of my head:

Textual, an IRC client [1, 2]

Blink, a SIP client [3, 4]...this is pretty difficult to compile, though...

-----

[1] https://itunes.apple.com/us/app/textual/id403012667

[2] https://github.com/Codeux/Textual

[3] https://itunes.apple.com/us/app/blink-lite/id431473881

[4] http://icanblink.com/download.phtml

Kerrick 13 years ago | | |

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

[0]: https://itunes.apple.com/us/app/cyberduck/id409222199 [1]: http://cyberduck.ch [2]: https://trac.cyberduck.ch/browser

dkl 13 years ago | | |

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

gjtorikian 13 years ago | | |

I never thought about it like that. I bought Textual because I wanted to support the developers.

The benefit of it being open-source was that I could try it, use it, and hack it, before deciding they'd done a damn good job.

nnq 13 years ago | | |

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

butterflyhug 13 years ago | |

Couple this with amerine's suggestion to allow release packages from private repos, and developers could also use GitHub to sell closed-source software.

wise_young_man 13 years ago | |

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

amerine 13 years ago |

It would be amazing to have public Releases from a private repo.

gfosco 13 years ago | |

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.

bluetidepro 13 years ago | |

+1 - I would LOVE this feature.

frakkingcylons 13 years ago | |

GitHub, if you're reading this, please add this feature!

archagon 13 years ago | |

Extra-awesome if we could include a snapshot of the source code without the git repo or commits.

zphds 13 years ago | | |

  git archive HEAD --format=zip > release_v1.zip

And then ship the code.

xpaulbettsx 13 years ago |

Here's a few examples of Releases:

    https://github.com/reactiveui/reactiveui/releases
    https://github.com/github/akavache/releases
    https://github.com/xpaulbettsx/splat/releases

DanielRibeiro 13 years ago | |

Link form:

https://github.com/reactiveui/reactiveui/releases

https://github.com/github/akavache/releases

https://github.com/xpaulbettsx/splat/releases

secure 13 years ago |

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?

ejdyksen 13 years ago |

Cool! We finally have downloads back!

It looks like this fails on tag names that have a slash in them.

jeremymcanally 13 years ago | |

Whoops. File a support ticket (e-mail support@github.com), please! That'd be uber helpful.

ejdyksen 13 years ago | | |

Done and done. Thanks!

wise_young_man 13 years ago | |

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.

philipn 13 years ago |

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!

burntsushi 13 years ago | |

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.

gr2020 13 years ago | | |

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.

burntsushi 13 years ago | | |

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

dlitz 13 years ago | | |

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:

    $ git ls-remote https://github.com/dlitz/pycrypto
    10abfc8633bac653eda4d346fc051b2f07554dcd        HEAD
    ...
    a1bfcc4a20ab0def053df75db0bb12644e55553e        refs/heads/cmac-wip
    fd398a28e3a227a539b264a9f1e11287b904c7da        refs/heads/hash-speedup-wip
    10abfc8633bac653eda4d346fc051b2f07554dcd        refs/heads/master
    606b17789c1869597466c714134f138c51b938f5        refs/pull/1/head
    7c3c142321f6aeb3e9ff502876e133d5350018e1        refs/pull/10/head
    52fe776815416ce61a516ca060f93405b3cdf7cb        refs/pull/10/merge
    0c2bb473529795d29ad43ce0d14162d1e2c19027        refs/pull/11/head
    ...
    00d0670bd7dca6bfb1c2dadaa76eaa364930ef78        refs/tags/v1.9a5
    aae6caac7874411e311f034e3547a6412fe2f362        refs/tags/v2.0.1
    40ae4256452c5cde1e714e3271af5028e96c5e1f        refs/tags/v2.0.1^{}
    d1ee050420f9a0fdacbf7c9f98c923ddfcc2a39f        refs/tags/v2.1.0
    033fc936155115b3a541387804e0a94820978498        refs/tags/v2.1.0^{}
    812e01736ca936124daa36d15a4159e92a43b9db        refs/tags/v2.1.0alpha1
    a7748d0e65fe17fbcb20f7b086536c3ccf68de43        refs/tags/v2.1.0alpha2
    ...

gr2020 13 years ago | |

Agree - would be awesome if the release notes were stored as part of the git repo, and editable from anywhere.

caf 13 years ago | | |

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.

cocoflunchy 13 years ago |

This sounds like the death of SourceForge. (I know, you could argue that it's already dead, and also argue that it's very much alive)

ionforce 13 years ago | |

Schrödinger's source code repository?

wubbfindel 13 years ago | | |

Only if no body checks to see if it is still alive (used by anyone), which in this case would kind of kill it.

reidrac 13 years ago |

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!

[1]: https://github.com/blog/1302-goodbye-uploads

frewsxcv 13 years ago |

Here's an example in action:

https://github.com/git-tfs/git-tfs/releases

mweibel 13 years ago |

I like it a lot :) One question though: Will there be graphs about the number of downloads of those release files?

togasystems 13 years ago |

Excited for this! No more view raw and save.

Kiro 13 years ago | |

Why would you ever do that instead of just download as zip or clone?

foca 13 years ago | | |

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.

edit For example, `curl https://raw.github.com/documentcloud/backbone/master/backbon... > js/lib/backbone-min.js`

Kiro 13 years ago | | |

Thanks, but why would Releases solve this?

foca 13 years ago | | |

I have no idea :P

But that's the case for which I use raw + save instead of download the zip / clone :)

sandyarmstrong 13 years ago |

Any news on if/when an API for this is coming? Could be super useful.

conroy 13 years ago | |

I'm waiting for this too.

leafo 13 years ago |

Excellent timing, just released a new version of MoonScript today, here it is in release form: https://github.com/leafo/moonscript/releases/v0.2.4

adamlj 13 years ago |

Goodbye SourceForge!

thomas_h 13 years ago |

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

hrjet 13 years ago |

Wonderful, however the UI for upload sucks.

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.

polymathist 13 years ago |

Well done. This will work quite well with Vincent Driessen's "A Successful Git Branching Model." http://nvie.com/posts/a-successful-git-branching-model/ And with nearly all sensible git branching models for that matter.

zachgersh 13 years ago |

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.

harrisonpowers 13 years ago |

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!

pkamb 13 years ago |

If you offer paid downloads from a private repository, preferably with an integrated licensing system, I'll be your first customer.

conductor 13 years ago |

GitHub, thank you for this.

Also, you used to have ZIP and Tarball downloads in the past, can you please bring back the Tarball downloads?

leif 13 years ago | |

The tarball releases are still there...

Spiritus 13 years ago |

Hmm, tried to draft a release. But after saving I'm only getting http 500 errors on the release page.

aspir 13 years ago | |

Shoot an email to support@github.com with a link to your repository. A 500 isn't an intended feature :)

brendanobrien 13 years ago |

wahoo!