2
2
Release libv8
3
3
*************
4
4
5
- We will start with building Ubuntu PPA first as it used in further CI process to validate that ``php-v8 `` is not broken.
5
+ Currently Docker is the recommended way to distribute and use both php-v8 and libv8 itself. We also support building
6
+ ``libv8 `` in macOS with Homebrew via `phpv8/tap `_ tap.
6
7
7
8
To track v8 changes you can use these links:
8
9
9
10
* https://github.com/v8/v8/commits/master/include/v8.h - to keep track on v8 upstream changes
10
11
* https://omahaproxy.appspot.com/ - to keep track v8 channel(version) heads and what version is used in chrome
11
12
12
- Building libv8
13
- ==============
13
+ Building docker image
14
+ =====================
14
15
15
- #. **Skip this step if you are updating v8 patch release version. ** To bump minor v8 version (e.g. from 6.3 to 6.4),
16
- create new ``libv8-X.Y `` PPA for new version. As V8 could be build for ``i386 `` but only from ``amd64 ``, which is not how PPA
17
- works, it's also make sense to keep new PPA ``amd64 ``-only. Also we don't use ``i386 `` so we don't want to worry about it.
18
- #. Update libv8 Makefile (``packaging/libv8/Makefile ``) with new libv8 version by setting proper values in
19
- ``GIT_VERSION=X.Y.Z `` and ``NAME=libv8-X.Y `` variables.
20
- #. Commit changes with ``build libv8 `` commit message and wait until libv8 PPA build done.
21
-
22
- After libv8 PPA build done
23
- ==========================
24
-
25
- #. Copy fresh ``libv8-X.Y `` build packages from ``experimental `` (default target for all libv8 builds we trigger)
26
- to it ``libv8-X.Y `` PPA. Do not rebuild, just copy binaries.
27
- #. **Wait for packages copied and published! **
28
- #. Build `phpv8/libv8 `_ docker image, tag it with the
29
- relevant v8 full version and push to Docker Hub.
16
+ #. Build `phpv8/libv8 `_ docker image, tag it with the relevant v8 full version and push to Docker Hub.
17
+ Hint: use ``Makefile ``.
30
18
#. You may want to set proper ``V8 `` version in ``php-v8 `` by updating it in ``.travis.yml ``.
31
- #. Make sure you have proper ``V8 `` version set in ``packaging/Dockerfile `` under ``V8 `` constant.
32
19
33
20
After docker images rebuilt/published
34
21
=====================================
@@ -40,11 +27,8 @@ After docker images rebuilt/published
40
27
#. Also, update references to v8 version in `php-v8 `_/scripts/provision/provision.sh,
41
28
it's normally could be done by replacing old version with new, e.g. ``6.3 `` => ``6.4 ``.
42
29
#. On every version bump update `php-v8 `_ ``README.md `` file with proper min v8 version required/tested.
43
- #. If you use vagrant, re-provision your local development environment at this step to fetch/add new ``libv8 `` version.
44
- It's generally a good idea to remove old ``libv8 `` versions as well and remove their PPA from apt sources list at this point.
45
30
#. **Make sure ** you tested `php-v8 `_ locally first before pushing to remote,
46
- upgrading v8 could be tricky as it may break BC even in patch releases (that's why we started to have separate
47
- PPAs for minor version to somehow couple with this issue in minor releases).
31
+ upgrading v8 could be tricky as it may break BC even in patch releases.
48
32
#. Note, that doing all this in a separate branch and merging that later into master is a nice and safe idea
49
33
(note, you may skip PR overhead and do fast-forward merge locally to master).
50
34
#. Commit message should state that it is v8 version bump, e.g. ``Require libv8 >= X.Y.Z ``
@@ -61,3 +45,4 @@ Building packages for macOS Homebrew
61
45
62
46
.. _php-v8 : https://github.com/phpv8/php-v8
63
47
.. _phpv8/libv8 : https://github.com/phpv8/dockerfiles/tree/master/libv8
48
+ .. _phpv8/tap : https://github.com/phpv8/homebrew-tap
0 commit comments