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
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...?
this looks really good.
git clone
make clean; make installTwo 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
https://github.com/reactiveui/reactiveui/releases
https://github.com/github/akavache/releases
https://github.com/xpaulbettsx/splat/releasesI 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?
It looks like this fails on tag names that have a slash in them.
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!
edit For example, `curl https://raw.github.com/documentcloud/backbone/master/backbon... > js/lib/backbone-min.js`
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.
Also, you used to have ZIP and Tarball downloads in the past, can you please bring back the Tarball downloads?
* this blurb: Factor.io lets developers automate the most tedious processes in minutes, not weeks, so they can ship with ease.
* a link to pricing info, which I'm not interested in because I don't know anything about your product
* a sign-up form, which I'm not interested in because I don't know anything about your product
* one tiny screenshot embedded in a picture of a laptop
and that's about it. You need more screenshots, a video, a list of features, etc.
[0]: https://itunes.apple.com/us/app/cyberduck/id409222199 [1]: http://cyberduck.ch [2]: https://trac.cyberduck.ch/browser
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.
$ 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
...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.
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