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