Release libv8

Currently Docker is the recommended way to distribute and use both php-v8 and libv8 itself. We also support building libv8 in macOS with Homebrew via phpv8/tap tap.

To track v8 changes you can use these links:

Building docker image

  1. Build phpv8/libv8 docker image, tag it with the relevant v8 full version and push to Docker Hub. Hint: use Makefile.
  2. You may want to set proper V8 version in php-v8 by updating it in .travis.yml.

After docker images rebuilt/published

  1. Update min required libv8 version in php-v8 config.m4, V8_MIN_API_VERSION_STR=X.Y.Z.
  2. If there was new docker images published, update reference to them in php-v8 .travis.yml and in php-v8 Dockerfile, and set proper V8 and TAG value there.
  3. Update reference to v8@X.Y in php-v8 CMakeLists.txt on minor version bump.
  4. Also, update references to v8 version in php-v8/scripts/provision/provision.sh, it’s normally could be done by replacing old version with new, e.g. 6.3 => 6.4.
  5. On every version bump update php-v8 README.md file with proper min v8 version required/tested.
  6. Make sure you tested php-v8 locally first before pushing to remote, upgrading v8 could be tricky as it may break BC even in patch releases.
  7. Note, that doing all this in a separate branch and merging that later into master is a nice and safe idea (note, you may skip PR overhead and do fast-forward merge locally to master).
  8. Commit message should state that it is v8 version bump, e.g. Require libv8 >= X.Y.Z
  9. Push changes and make sure build is green. If not, fix code/update tests and repeat.

Building packages for macOS Homebrew

  1. Skip this step if you are updating v8 patch release version. If it is a minor version bump, create new v8@X.Y formula.
  2. Skip this step if you are updating v8 patch release version. Create new v8:X.Y Package on bintray for it.
  3. Remove/reset formula revision if it is version bump and not rebuild.
  4. Build v8@X.Y (locally or with TravisCI if it provides relevant macOS version) and publish.