Distributing Project Artifacts

Once you've published your project, you may want to publish artifacts such as source code archives or pre-compiled binaries when you cut a new stable release. Additionally, many communities have specific distribution channels where projects or libraries are expected to be found.

Source code archives {#source}

Both GitHub and go/gob support auto-generated archives of a repository's source code at a given ref. Simply by constructing the URL, you can link users to a downloadable archive of your project source code. Note that these only contain the source at that ref, not the full history of the repository. For example, the 1.6.2 release of Go is tagged "go1.6.2" in git, and so can be retrieved at any of:

  • http://linkremoved/
  • https://github.com/golang/go/archive/go1.6.2.tar.gz
  • https://github.com/golang/go/archive/go1.6.2.zip

GitHub Releases {#github-releases}

If you need to ship additional artifacts as part of a release such as compiled binaries or documentation, you can use GitHub Releases. In addition to the auto-generated source code archives noted above, you can can provide release notes as well as binary attachments as part of release. As an example, see the google/protobuf releases page. Note that, at the time of writing, these attachments are limited to 2 GB each.

Google Cloud Storage {#cloud-storage}

For projects not hosted on GitHub or that need support for larger files than GitHub allows, we recommend Google Cloud Storage. This is strongly recommended over Google Drive so that ownership of the files is not tied to a single team member's account. For example, the Go team uses GCS for their binary releases on http://linkremoved/

Package repositories {#repositories}

Many communities have central repositories of packages and libraries, and Google has an official presence on many of them. The sections below provide instructions for releasing in these various repositories and who to contact for help or to get access.

If you have any questions, contact emailremoved@.

Debian {#debian}

If you want to provide source code to Debian, for the Debian project to compile and package a binary artifact that it distributes via apt, please follow this process. You may only make contributions to "main" or "contrib". Never "nonfree".

  1. Make sure the source you want to release has gone through go/releasing first.
  2. Make sure you are not distributing source to Debian that Google does not own, for example vendored third_party dependencies. If you are, please email emailremoved@, citing this policy, and explain. If your binary has third-party compile-time dependencies that the Debian project will pull, that is fine and does not require review.

Bintray {#bintray}

Read the Bintray guide.

Maven (Java) {#maven}

Read the Maven guide.

npm (JavaScript) {#npm}

Read the npm guide.

Packagist (PHP) {#packagist}

Account: https://packagist.org/packages/google/

TODO

PyPI (Python) {#pypi}

  1. Please review the OSPO guidelines on creating and releasing code publicly (go/releasing).
  2. Figure out a good name for your project. Python packages all share a global namespace, so pick a good name that isn't taken by another package or would be confused with another package.
  3. Read through the general tutorial on packaging python projects.
  4. If you have questions or issues creating your setup.py or your project has complex distribution needs reach out to emailremoved@ for assistance.
  5. If your packages want to use the google import namespace (for example if you want your package to be import google.something) you must reach out to emailremoved@ and emailremoved@ to coordinate. Releasing a broken namespace package will break Python installations.
  6. Create an account on pypi.org specifically for your team or package. Store the password in go/cupid and share it with your team.
  7. Upload your package as that account.
  8. Once your package is uploaded use the pypi.org management interface to add google_opensource as a owner on the package.
  9. You may add additional accounts to the package as needed, but do not remove the google_opensource account.

RubyGems

TODO

WordPress plugins {#wordpress}

Account: http://linkremoved/

TODO

Visual Studio Marketplace {#visualstudio}

Releases of Visual Studio extensions should be approved by your team's product counsel (go/whichlawyer).

Account: http://linkremoved/
Contact: emailremoved@

TODO(**********): mention go/code-signing-certificates in relevant place