what is the best practice of distributing binaries from a github project?
what is the best practice of distributing binaries from a github project?
I can think of:
- Create a bin folder in your project where you keep a copy of the binaries. However, github is meant to store source code and not binaries Storing large and regularly changing binaries may be expensive qua diskspace and bandwidth?
- Upload a copy of the binaries to the github pages of the project, or use a separate web site for hosting your binaries. However, that is not always feasible, and requires more (hand)work to keep the binaries up to date, I rather want to have the binaries updated automatically or with a single action.
Answer
As of December 11, 2012 the Downloads feature on GitHub is deprecated. The article Distributing large binaries recommends using an external service:
We recommend Amazon S3 for storage paired with CloudFront for serving via CDN, or other services such as SourceForge.
However, since 2d July 2013, you now can define a release.
Releases, a workflow for shipping software to end users.
Releases are first-class objects with changelogs and binary assets that present a full project history beyond Git artifacts. They're accessible from a repository's homepage:
- Releases are accompanied by release notes and links to download the software or source code.
- Following the conventions of many Git projects, releases are tied to Git tags. You can use an existing tag, or let releases create the tag when it's published.
- You can also attach binary assets (such as compiled executables, minified scripts, documentation) to a release. Once published, the release details and assets are available to anyone that can view the repository.
