what is the best practice of distributing binaries from a github project? [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 8 years ago.

Improve this question

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 1

It is clear to me now that it is important not to store binaries in your github project itself. Thus, you will need to store binaries elsewhere. Possible solutions I came across are:

• Store the binaries in a separate submodule (dalores idea). It makes sense to store them in your projects github pages, which you use to host your projects website via github.
• If you have only a few binaries or zip file only, you can upload them to github via Downloads -> Upload a new file. This feature is quite limited though, you cannot put files in structured folders.
• In case of java jar files, there are solutions out there like Nexus for managing your libraries.
• Store the binaries on a completely separate site that you host yourself

Answer 2

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.

Answer 3

What kind of binaries? The binaries must have come from source at some point right?

So add the source that builds those binaries as a submodule in git. Then in your build process build those binaries first before building your source. The submodule is kept in sync to a specific version of the source you know that works. You also get the benefit of being able to debug easier since you have the source.

Unless the binaries are images etc, then just store those.

If space is the issue use bitbucket as they have unlimited space.