Buck: .buckversion


If the root of your project contains a file named .buckversion, then Buck will expect that file to contain a Git hash and an optional branch that specifies the version of Buck that should be used to build your project.

The contents of .buckversion are expected to be in the format

[Buck git hash]:[Optional Remote branch]

For example, the following would both be valid .buckversion files:

  • abcdef1234567890
  • abcdef1234567890:refs/releases/release-01-10-2013

If .buckversion is present, then bin/buck will compare the value in .buckversion with the value of git rev-parse HEAD in the directory where you checked out Buck from Git. If the values differ, then Buck will update itself to the revision that you specified (using git fetch, tracking the remote branch if needed, and git checkout), and then rebuild itself.

If .buckversion is not present, then Buck assumes it is at the correct revision. In that scenario, bin/buck will only rebuild Buck if the compiled .class files for Buck are not present.

At Facebook, Buck has undergone rapid change, so if a new version of a binary version of Buck needed to be checked to the projects that use it every time Buck were updated, then those projects' version control histories would be littered with Buck binaries. Relying on this .buckversion scheme has made it possible to keep those repositories free of Buck binaries while iterating quickly on Buck.

To disable this behavior, you can either:

  • Remove the .buckversion file.
  • Add a .nobuckcheck file. See the article on .nobuckcheck for details
Note that normally, a Git hash in .buckversion will be one on the master branch of Buck as hosted by Facebook on GitHub. However, if you create your own fork of Buck that developers check out, then this scheme should work just as well with the hashes from your forked repo.