diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst
index 5f62376..b80354a 100644
--- a/poky/documentation/bsp-guide/bsp.rst
+++ b/poky/documentation/bsp-guide/bsp.rst
@@ -1042,7 +1042,7 @@
 #. Edit the ``init-ifupdown_1.0.bbappend`` file so that it contains the
    following::
 
-      FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+      FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
 
    The append file needs to be in the ``meta-xyz/recipes-core/init-ifupdown``
    directory.
@@ -1269,9 +1269,9 @@
    include conf/machine/include/tune-cortexa8.inc
 
    IMAGE_FSTYPES += "tar.bz2 jffs2 wic wic.bmap"
-   EXTRA_IMAGECMD_jffs2 = "-lnp "
+   EXTRA_IMAGECMD:jffs2 = "-lnp "
    WKS_FILE ?= "beaglebone-yocto.wks"
-   IMAGE_INSTALL_append = " kernel-devicetree kernel-image-zimage"
+   IMAGE_INSTALL:append = " kernel-devicetree kernel-image-zimage"
    do_image_wic[depends] += "mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot"
 
    SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0"
@@ -1458,29 +1458,29 @@
 
 Following is the contents of the append file::
 
-   KBRANCH_genericx86 = "v5.0/standard/base"
-   KBRANCH_genericx86-64 = "v5.0/standard/base"
-   KBRANCH_edgerouter = "v5.0/standard/edgerouter"
-   KBRANCH_beaglebone-yocto = "v5.0/standard/beaglebone"
+   KBRANCH:genericx86 = "v5.0/standard/base"
+   KBRANCH:genericx86-64 = "v5.0/standard/base"
+   KBRANCH:edgerouter = "v5.0/standard/edgerouter"
+   KBRANCH:beaglebone-yocto = "v5.0/standard/beaglebone"
 
-   KMACHINE_genericx86 ?= "common-pc"
-   KMACHINE_genericx86-64 ?= "common-pc-64"
-   KMACHINE_beaglebone-yocto ?= "beaglebone"
+   KMACHINE:genericx86 ?= "common-pc"
+   KMACHINE:genericx86-64 ?= "common-pc-64"
+   KMACHINE:beaglebone-yocto ?= "beaglebone"
 
-   SRCREV_machine_genericx86 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
-   SRCREV_machine_genericx86-64 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
-   SRCREV_machine_edgerouter ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
-   SRCREV_machine_beaglebone-yocto ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
+   SRCREV_machine:genericx86 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
+   SRCREV_machine:genericx86-64 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
+   SRCREV_machine:edgerouter ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
+   SRCREV_machine:beaglebone-yocto ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
 
-   COMPATIBLE_MACHINE_genericx86 = "genericx86"
-   COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
-   COMPATIBLE_MACHINE_edgerouter = "edgerouter"
-   COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
+   COMPATIBLE_MACHINE:genericx86 = "genericx86"
+   COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
+   COMPATIBLE_MACHINE:edgerouter = "edgerouter"
+   COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
 
-   LINUX_VERSION_genericx86 = "5.0.3"
-   LINUX_VERSION_genericx86-64 = "5.0.3"
-   LINUX_VERSION_edgerouter = "5.0.3"
-   LINUX_VERSION_beaglebone-yocto = "5.0.3"
+   LINUX_VERSION:genericx86 = "5.0.3"
+   LINUX_VERSION:genericx86-64 = "5.0.3"
+   LINUX_VERSION:edgerouter = "5.0.3"
+   LINUX_VERSION:beaglebone-yocto = "5.0.3"
 
 This particular append file works for all the machines that are
 part of the ``meta-yocto-bsp`` layer. The relevant statements are
diff --git a/poky/documentation/conf.py b/poky/documentation/conf.py
index 6c6458f..8e15fdc 100644
--- a/poky/documentation/conf.py
+++ b/poky/documentation/conf.py
@@ -28,7 +28,7 @@
 
 # -- Project information -----------------------------------------------------
 project = 'The Yocto Project \xae'
-copyright = '2010-%s, The Linux Foundation' % datetime.datetime.now().year
+copyright = '2010-%s, The Linux Foundation, CC-BY-SA-2.0-UK license' % datetime.datetime.now().year
 author = 'The Linux Foundation'
 
 # -- General configuration ---------------------------------------------------
diff --git a/poky/documentation/dev-manual/common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst
index 7fa0df4..7f51674 100644
--- a/poky/documentation/dev-manual/common-tasks.rst
+++ b/poky/documentation/dev-manual/common-tasks.rst
@@ -207,37 +207,37 @@
       To make sure your changes apply only when building machine "one",
       use a machine override with the :term:`DEPENDS` statement::
 
-         DEPENDS_one = "foo"
+         DEPENDS:one = "foo"
 
-      You should follow the same strategy when using ``_append``
-      and ``_prepend`` operations::
+      You should follow the same strategy when using ``:append``
+      and ``:prepend`` operations::
 
-         DEPENDS_append_one = " foo"
-         DEPENDS_prepend_one = "foo "
+         DEPENDS:append:one = " foo"
+         DEPENDS:prepend:one = "foo "
 
       As an actual example, here's a
       snippet from the generic kernel include file ``linux-yocto.inc``,
       wherein the kernel compile and link options are adjusted in the
       case of a subset of the supported architectures::
 
-         DEPENDS_append_aarch64 = " libgcc"
-         KERNEL_CC_append_aarch64 = " ${TOOLCHAIN_OPTIONS}"
-         KERNEL_LD_append_aarch64 = " ${TOOLCHAIN_OPTIONS}"
+         DEPENDS:append:aarch64 = " libgcc"
+         KERNEL_CC:append:aarch64 = " ${TOOLCHAIN_OPTIONS}"
+         KERNEL_LD:append:aarch64 = " ${TOOLCHAIN_OPTIONS}"
 
-         DEPENDS_append_nios2 = " libgcc"
-         KERNEL_CC_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
-         KERNEL_LD_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
+         DEPENDS:append:nios2 = " libgcc"
+         KERNEL_CC:append:nios2 = " ${TOOLCHAIN_OPTIONS}"
+         KERNEL_LD:append:nios2 = " ${TOOLCHAIN_OPTIONS}"
 
-         DEPENDS_append_arc = " libgcc"
-         KERNEL_CC_append_arc = " ${TOOLCHAIN_OPTIONS}"
-         KERNEL_LD_append_arc = " ${TOOLCHAIN_OPTIONS}"
+         DEPENDS:append:arc = " libgcc"
+         KERNEL_CC:append:arc = " ${TOOLCHAIN_OPTIONS}"
+         KERNEL_LD:append:arc = " ${TOOLCHAIN_OPTIONS}"
 
-         KERNEL_FEATURES_append_qemuall=" features/debug/printk.scc"
+         KERNEL_FEATURES:append:qemuall=" features/debug/printk.scc"
 
       .. note::
 
-         Avoiding "+=" and "=+" and using machine-specific ``_append``
-         and ``_prepend`` operations is recommended as well.
+         Avoiding "+=" and "=+" and using machine-specific ``:append``
+         and ``:prepend`` operations is recommended as well.
 
    -  *Place Machine-Specific Files in Machine-Specific Locations:* When
       you have a base recipe, such as ``base-files.bb``, that contains a
@@ -247,7 +247,7 @@
       at ``meta-one/recipes-core/base-files/base-files.bbappend`` could
       extend :term:`FILESPATH` using :term:`FILESEXTRAPATHS` as follows::
 
-         FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
+         FILESEXTRAPATHS:prepend := "${THISDIR}/${BPN}:"
 
       The build for machine "one" will pick up your machine-specific file as
       long as you have the file in
@@ -443,8 +443,8 @@
 adds the recipes, classes and configurations contained within the
 particular layer to the source directory.
 
-Using .bbappend Files in Your Layer
------------------------------------
+Appending Other Layers Metadata With Your Layer
+-----------------------------------------------
 
 A recipe that appends Metadata to another recipe is called a BitBake
 append file. A BitBake append file uses the ``.bbappend`` file type
@@ -465,7 +465,7 @@
 When you create an append file, you must use the same root name as the
 corresponding recipe file. For example, the append file
 ``someapp_3.1.bbappend`` must apply to ``someapp_3.1.bb``. This
-means the original recipe and append file names are version
+means the original recipe and append filenames are version
 number-specific. If the corresponding recipe is renamed to update to a
 newer version, you must also rename and possibly update the
 corresponding ``.bbappend`` as well. During the build process, BitBake
@@ -474,6 +474,9 @@
 :term:`BB_DANGLINGAPPENDS_WARNONLY`
 variable for information on how to handle this error.
 
+Overlaying a File Using Your Layer
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 As an example, consider the main formfactor recipe and a corresponding
 formfactor append file both from the :term:`Source Directory`.
 Here is the main
@@ -512,7 +515,7 @@
 and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The
 file is in the layer at ``recipes-bsp/formfactor``::
 
-   FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+   FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
 
 By default, the build system uses the
 :term:`FILESPATH` variable to
@@ -537,7 +540,7 @@
 .. note::
 
    BitBake automatically defines the :term:`THISDIR` variable. You should
-   never set this variable yourself. Using "_prepend" as part of the
+   never set this variable yourself. Using ":prepend" as part of the
    :term:`FILESEXTRAPATHS` ensures your path will be searched prior to other
    paths in the final list.
 
@@ -545,6 +548,12 @@
    allow to add build options (e.g. ``systemd``). For these cases, your
    append file would not even use the :term:`FILESEXTRAPATHS` statement.
 
+The end result of this ``.bbappend`` file is that on a Raspberry Pi, where
+``rpi`` will exist in the list of :term:`OVERRIDES`, the file
+``meta-raspberrypi/recipes-bsp/formfactor/formfactor/rpi/machconfig`` will be
+used during :ref:`ref-tasks-fetch` and the test for a non-zero file size in
+:ref:`ref-tasks-install` will return true, and the file will be installed.
+
 Prioritizing Your Layer
 -----------------------
 
@@ -830,27 +839,27 @@
 all images, which might not be what you require.
 
 To add a package to your image using the local configuration file, use
-the :term:`IMAGE_INSTALL` variable with the ``_append`` operator::
+the :term:`IMAGE_INSTALL` variable with the ``:append`` operator::
 
-   IMAGE_INSTALL_append = " strace"
+   IMAGE_INSTALL:append = " strace"
 
 Use of the syntax is important -
 specifically, the space between the quote and the package name, which is
-``strace`` in this example. This space is required since the ``_append``
+``strace`` in this example. This space is required since the ``:append``
 operator does not add the space.
 
-Furthermore, you must use ``_append`` instead of the ``+=`` operator if
+Furthermore, you must use ``:append`` instead of the ``+=`` operator if
 you want to avoid ordering issues. The reason for this is because doing
 so unconditionally appends to the variable and avoids ordering problems
 due to the variable being set in image recipes and ``.bbclass`` files
-with operators like ``?=``. Using ``_append`` ensures the operation
+with operators like ``?=``. Using ``:append`` ensures the operation
 takes effect.
 
-As shown in its simplest use, ``IMAGE_INSTALL_append`` affects all
+As shown in its simplest use, ``IMAGE_INSTALL:append`` affects all
 images. It is possible to extend the syntax so that the variable applies
 to a specific image only. Here is an example::
 
-   IMAGE_INSTALL_append_pn-core-image-minimal = " strace"
+   IMAGE_INSTALL:append:pn-core-image-minimal = " strace"
 
 This example adds ``strace`` to the ``core-image-minimal`` image only.
 
@@ -976,17 +985,17 @@
        ${PN}-tools \
        "
 
-   RDEPENDS_${PN}-apps = "\
+   RDEPENDS:${PN}-apps = "\
        dropbear \
        portmap \
        psplash"
 
-   RDEPENDS_${PN}-tools = "\
+   RDEPENDS:${PN}-tools = "\
        oprofile \
        oprofileui-server \
        lttng-tools"
 
-   RRECOMMENDS_${PN}-tools = "\
+   RRECOMMENDS:${PN}-tools = "\
        kernel-module-oprofile"
 
 In the previous example, two package group packages are created with
@@ -1013,7 +1022,7 @@
 
 Use the following in a configuration file::
 
-   hostname_pn-base-files = "myhostname"
+   hostname:pn-base-files = "myhostname"
 
 Changing the default value of the variable "hostname" can be useful in
 certain situations. For example, suppose you need to do extensive
@@ -1028,7 +1037,7 @@
 will have no default hostname in the filesystem. Here is an example that
 unsets the variable in a configuration file::
 
-  hostname_pn-base-files = ""
+  hostname:pn-base-files = ""
 
 Having no default hostname in the filesystem is suitable for
 environments that use dynamic hostnames such as virtual machines.
@@ -1544,8 +1553,8 @@
 name can be found through the
 ``${``\ :term:`PN`\ ``}`` variable, then
 you specify the dependencies for the main package by setting
-``RDEPENDS_${PN}``. If the package were named ``${PN}-tools``, then you
-would set ``RDEPENDS_${PN}-tools``, and so forth.
+``RDEPENDS:${PN}``. If the package were named ``${PN}-tools``, then you
+would set ``RDEPENDS:${PN}-tools``, and so forth.
 
 Some runtime dependencies will be set automatically at packaging time.
 These dependencies include any shared library dependencies (i.e. if a
@@ -1796,7 +1805,7 @@
    sure the install portion of the build completes with no issues.
    However, if you wish to install additional files not already being
    installed by ``make install``, you should do this using a
-   ``do_install_append`` function using the install command as described
+   ``do_install:append`` function using the install command as described
    in the "Manual" bulleted item later in this list.
 
 -  *Other (using* ``make install``\ *)*: You need to define a ``do_install``
@@ -1865,9 +1874,9 @@
 
 If you are adding services and the service initialization script or the
 service file itself is not installed, you must provide for that
-installation in your recipe using a ``do_install_append`` function. If
+installation in your recipe using a ``do_install:append`` function. If
 your recipe already has a ``do_install`` function, update the function
-near its end rather than adding an additional ``do_install_append``
+near its end rather than adding an additional ``do_install:append``
 function.
 
 When you create the installation for your services, you need to
@@ -1938,7 +1947,7 @@
    discover problems, you can set
    :term:`PACKAGES`,
    :term:`FILES`,
-   ``do_install(_append)``, and so forth as needed.
+   ``do_install(:append)``, and so forth as needed.
 
 -  *Splitting an Application into Multiple Packages*: If you need to
    split an application into several packages, see the
@@ -2137,7 +2146,7 @@
 Post-installation scripts run immediately after installing a package on
 the target or during image creation when a package is included in an
 image. To add a post-installation script to a package, add a
-``pkg_postinst_``\ `PACKAGENAME`\ ``()`` function to the recipe file
+``pkg_postinst:``\ `PACKAGENAME`\ ``()`` function to the recipe file
 (``.bb``) and replace `PACKAGENAME` with the name of the package you want
 to attach to the ``postinst`` script. To apply the post-installation
 script to the main package for the recipe, which is usually what is
@@ -2147,7 +2156,7 @@
 
 A post-installation function has the following structure::
 
-   pkg_postinst_PACKAGENAME() {
+   pkg_postinst:PACKAGENAME() {
        # Commands to carry out
    }
 
@@ -2300,7 +2309,7 @@
 path. You can accomplish this by adding to the :term:`CFLAGS` variable. The
 following example shows this::
 
-   CFLAGS_prepend = "-I ${S}/include "
+   CFLAGS:prepend = "-I ${S}/include "
 
 In the following example, ``mtd-utils`` is a makefile-based package::
 
@@ -2330,9 +2339,9 @@
 
    PACKAGES =+ "mtd-utils-jffs2 mtd-utils-ubifs mtd-utils-misc"
 
-   FILES_mtd-utils-jffs2 = "${sbindir}/mkfs.jffs2 ${sbindir}/jffs2dump ${sbindir}/jffs2reader ${sbindir}/sumtool"
-   FILES_mtd-utils-ubifs = "${sbindir}/mkfs.ubifs ${sbindir}/ubi*"
-   FILES_mtd-utils-misc = "${sbindir}/nftl* ${sbindir}/ftl* ${sbindir}/rfd* ${sbindir}/doc* ${sbindir}/serve_image ${sbindir}/recv_image"
+   FILES:mtd-utils-jffs2 = "${sbindir}/mkfs.jffs2 ${sbindir}/jffs2dump ${sbindir}/jffs2reader ${sbindir}/sumtool"
+   FILES:mtd-utils-ubifs = "${sbindir}/mkfs.ubifs ${sbindir}/ubi*"
+   FILES:mtd-utils-misc = "${sbindir}/nftl* ${sbindir}/ftl* ${sbindir}/rfd* ${sbindir}/doc* ${sbindir}/serve_image ${sbindir}/recv_image"
 
    PARALLEL_MAKE = ""
 
@@ -2360,14 +2369,14 @@
    XORG_PN = "libXpm"
 
    PACKAGES =+ "sxpm cxpm"
-   FILES_cxpm = "${bindir}/cxpm"
-   FILES_sxpm = "${bindir}/sxpm"
+   FILES:cxpm = "${bindir}/cxpm"
+   FILES:sxpm = "${bindir}/sxpm"
 
 In the previous example, we want to ship the ``sxpm`` and ``cxpm``
 binaries in separate packages. Since ``bindir`` would be packaged into
 the main :term:`PN` package by default, we prepend the :term:`PACKAGES` variable
 so additional package names are added to the start of list. This results
-in the extra ``FILES_*`` variables then containing information that
+in the extra ``FILES:*`` variables then containing information that
 define which files and directories go into which packages. Files
 included by earlier packages are skipped by latter packages. Thus, the
 main :term:`PN` package does not include the above listed files.
@@ -2398,7 +2407,7 @@
 from the appropriate area. In particular, this class sets ``noexec`` on
 both the :ref:`ref-tasks-configure`
 and :ref:`ref-tasks-compile` tasks,
-sets ``FILES_${PN}`` to "/" so that it picks up all files, and sets up a
+sets ``FILES:${PN}`` to "/" so that it picks up all files, and sets up a
 :ref:`ref-tasks-install` task, which
 effectively copies all files from ``${S}`` to ``${D}``. The
 ``bin_package`` class works well when the files extracted into ``${S}``
@@ -2459,7 +2468,7 @@
 
 -  Ensure that you set up :term:`FILES`
    (usually
-   ``FILES_${``\ :term:`PN`\ ``}``) to
+   ``FILES:${``\ :term:`PN`\ ``}``) to
    point to the files you have installed, which of course depends on
    where you have installed them and whether those files are in
    different locations than the defaults.
@@ -2504,7 +2513,7 @@
 
       S = "${WORKDIR}/postfix-${PV}"
       CFLAGS += "-DNO_ASM"
-      SRC_URI_append = " file://fixup.patch"
+      SRC_URI:append = " file://fixup.patch"
 
 -  *Functions:* Functions provide a series of actions to be performed.
    You usually use functions to override the default implementation of a
@@ -2631,7 +2640,7 @@
 
       VAR =+ "Starts"
 
--  *Appending (_append):* Use the ``_append`` operator to append values
+-  *Appending (:append):* Use the ``:append`` operator to append values
    to existing variables. This operator does not add any additional
    space. Also, the operator is applied after all the ``+=``, and ``=+``
    operators have been applied and after all ``=`` assignments have
@@ -2641,15 +2650,15 @@
    start to ensure the appended value is not merged with the existing
    value::
 
-      SRC_URI_append = " file://fix-makefile.patch"
+      SRC_URI:append = " file://fix-makefile.patch"
 
    You can also use
-   the ``_append`` operator with overrides, which results in the actions
+   the ``:append`` operator with overrides, which results in the actions
    only being performed for the specified target or machine::
 
-      SRC_URI_append_sh4 = " file://fix-makefile.patch"
+      SRC_URI:append:sh4 = " file://fix-makefile.patch"
 
--  *Prepending (_prepend):* Use the ``_prepend`` operator to prepend
+-  *Prepending (:prepend):* Use the ``:prepend`` operator to prepend
    values to existing variables. This operator does not add any
    additional space. Also, the operator is applied after all the ``+=``,
    and ``=+`` operators have been applied and after all ``=``
@@ -2659,13 +2668,13 @@
    end to ensure the prepended value is not merged with the existing
    value::
 
-      CFLAGS_prepend = "-I${S}/myincludes "
+      CFLAGS:prepend = "-I${S}/myincludes "
 
    You can also use the
-   ``_prepend`` operator with overrides, which results in the actions
+   ``:prepend`` operator with overrides, which results in the actions
    only being performed for the specified target or machine::
 
-      CFLAGS_prepend_sh4 = "-I${S}/myincludes "
+      CFLAGS:prepend:sh4 = "-I${S}/myincludes "
 
 -  *Overrides:* You can use overrides to set a value conditionally,
    typically based on how the recipe is being built. For example, to set
@@ -2676,7 +2685,7 @@
    you would do the following::
 
       KBRANCH = "standard/base"
-      KBRANCH_qemuarm = "standard/arm-versatile-926ejs"
+      KBRANCH:qemuarm = "standard/arm-versatile-926ejs"
 
    Overrides are also used to separate
    alternate values of a variable in other situations. For example, when
@@ -2951,7 +2960,7 @@
          If your distro does not enable by default ptest, which Poky
          does, you need the following in your ``local.conf`` file::
 
-                 DISTRO_FEATURES_append = " ptest"
+                 DISTRO_FEATURES:append = " ptest"
 
 
 6. *Optionally Start a vncserver:* If you are running in a server
@@ -4301,7 +4310,7 @@
 your ``local.conf`` file::
 
    INHERIT += "externalsrc"
-   EXTERNALSRC_pn-myrecipe = "path-to-your-source-tree"
+   EXTERNALSRC:pn-myrecipe = "path-to-your-source-tree"
 
 This next example shows how to accomplish the same thing by setting
 :term:`EXTERNALSRC` in the recipe itself or in the recipe's append file::
@@ -4323,7 +4332,7 @@
 :term:`EXTERNALSRC_BUILD`
 to point to that directory::
 
-   EXTERNALSRC_BUILD_pn-myrecipe = "path-to-your-source-tree"
+   EXTERNALSRC_BUILD:pn-myrecipe = "path-to-your-source-tree"
 
 Replicating a Build Offline
 ---------------------------
@@ -4538,7 +4547,7 @@
    exceptions::
 
       STATICLIBCONF = "--disable-static"
-      STATICLIBCONF_sqlite3-native = ""
+      STATICLIBCONF:sqlite3-native = ""
       EXTRA_OECONF += "${STATICLIBCONF}"
 
    .. note::
@@ -4578,7 +4587,7 @@
 the built library.
 
 The :term:`PACKAGES` and
-:term:`FILES_* <FILES>` variables in the
+:term:`FILES:* <FILES>` variables in the
 ``meta/conf/bitbake.conf`` configuration file define how files installed
 by the ``do_install`` task are packaged. By default, the :term:`PACKAGES`
 variable includes ``${PN}-staticdev``, which represents all static
@@ -4597,7 +4606,7 @@
    PACKAGES_DYNAMIC = "^${PN}-locale-.*"
    FILES = ""
 
-   FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
+   FILES:${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
                ${sysconfdir} ${sharedstatedir} ${localstatedir} \
                ${base_bindir}/* ${base_sbindir}/* \
                ${base_libdir}/*${SOLIBS} \
@@ -4607,24 +4616,24 @@
                ${datadir}/idl ${datadir}/omf ${datadir}/sounds \
                ${libdir}/bonobo/servers"
 
-   FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
+   FILES:${PN}-bin = "${bindir}/* ${sbindir}/*"
 
-   FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
+   FILES:${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
                ${datadir}/gnome/help"
-   SECTION_${PN}-doc = "doc"
+   SECTION:${PN}-doc = "doc"
 
    FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}"
-   FILES_${PN}-dev = "${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la \
+   FILES:${PN}-dev = "${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la \
                    ${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
                    ${datadir}/aclocal ${base_libdir}/*.o \
                    ${libdir}/${BPN}/*.la ${base_libdir}/*.la"
-   SECTION_${PN}-dev = "devel"
-   ALLOW_EMPTY_${PN}-dev = "1"
-   RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
+   SECTION:${PN}-dev = "devel"
+   ALLOW_EMPTY:${PN}-dev = "1"
+   RDEPENDS:${PN}-dev = "${PN} (= ${EXTENDPKGV})"
 
-   FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a ${libdir}/${BPN}/*.a"
-   SECTION_${PN}-staticdev = "devel"
-   RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
+   FILES:${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a ${libdir}/${BPN}/*.a"
+   SECTION:${PN}-staticdev = "devel"
+   RDEPENDS:${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
 
 Combining Multiple Versions of Library Files into One Image
 -----------------------------------------------------------
@@ -4701,8 +4710,8 @@
    MACHINE = "qemux86-64"
    require conf/multilib.conf
    MULTILIBS = "multilib:lib32"
-   DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
-   IMAGE_INSTALL_append = "lib32-glib-2.0"
+   DEFAULTTUNE:virtclass-multilib-lib32 = "x86"
+   IMAGE_INSTALL:append = "lib32-glib-2.0"
 
 This example enables an additional library named
 ``lib32`` alongside the normal target packages. When combining these
@@ -4749,7 +4758,7 @@
    :term:`Build Directory`. For
    example, consider ``lib32`` in a ``qemux86-64`` image. The possible
    architectures in the system are "all", "qemux86_64",
-   "lib32_qemux86_64", and "lib32_x86".
+   "lib32:qemux86_64", and "lib32:x86".
 
 -  The ``${MLPREFIX}`` variable is stripped from ``${PN}`` during RPM
    packaging. The naming for a normal RPM package and a Multilib RPM
@@ -4768,7 +4777,7 @@
 -  The ``${MLPREFIX}`` is not stripped from ``${PN}`` during IPK
    packaging. The naming for a normal RPM package and a Multilib IPK
    package in a ``qemux86-64`` system resolves to something like
-   ``bash_4.1-r2.x86_64.ipk`` and ``lib32-bash_4.1-rw_x86.ipk``,
+   ``bash_4.1-r2.x86_64.ipk`` and ``lib32-bash_4.1-rw:x86.ipk``,
    respectively.
 
 -  The IPK deploy folder is not modified with ``${MLPREFIX}`` because
@@ -4857,7 +4866,7 @@
 
    MACHINE = "qemux86-64"
    DEFAULTTUNE = "x86-64-x32"
-   baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE') \
+   baselib = "${@d.getVar('BASE_LIB:tune-' + (d.getVar('DEFAULTTUNE') \
        or 'INVALID')) or 'lib'}"
 
 Once you have set
@@ -6085,7 +6094,7 @@
 
    -  Add a ``psplash`` append file for a branded splash screen. For
       information on append files, see the
-      ":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
+      ":ref:`dev-manual/common-tasks:appending other layers metadata with your layer`"
       section.
 
    -  Add any other append files to make custom changes that are
@@ -6510,11 +6519,11 @@
 a pattern of files or directories under a specified path and creates a
 package for each one it finds by appending to the
 :term:`PACKAGES` variable and
-setting the appropriate values for ``FILES_packagename``,
-``RDEPENDS_packagename``, ``DESCRIPTION_packagename``, and so forth.
+setting the appropriate values for ``FILES:packagename``,
+``RDEPENDS:packagename``, ``DESCRIPTION:packagename``, and so forth.
 Here is an example from the ``lighttpd`` recipe::
 
-   python populate_packages_prepend () {
+   python populate_packages:prepend () {
        lighttpd_libdir = d.expand('${libdir}')
        do_split_packages(d, lighttpd_libdir, '^mod_(.*).so$',
                         'lighttpd-module-%s', 'Lighttpd module for %s',
@@ -6618,7 +6627,7 @@
       instead of the default False which appends them
    match_path
       match file_regex on the whole relative path to
-      the root rather than just the file name
+      the root rather than just the filename
    aux_files_pattern_verbatim
       Extra item(s) to be added to FILES for each
       package, using the actual derived module name
@@ -7101,7 +7110,7 @@
 variables to your ``local.conf`` file, which is found in the
 :term:`Build Directory`::
 
-   DISTRO_FEATURES_append = " ptest"
+   DISTRO_FEATURES:append = " ptest"
    EXTRA_IMAGE_FEATURES += "ptest-pkgs"
 
 Once your build is complete, the ptest files are installed into the
@@ -7145,7 +7154,7 @@
    your recipe in order for the package to meet the dependencies. Here
    is an example where the package has a runtime dependency on "make"::
 
-      RDEPENDS_${PN}-ptest += "make"
+      RDEPENDS:${PN}-ptest += "make"
 
 -  *Add a function to build the test suite:* Not many packages support
    cross-compilation of their test suites. Consequently, you usually
@@ -7289,11 +7298,11 @@
        "
    S = "${WORKDIR}/npm"
    inherit npm
-   LICENSE_${PN} = "MIT"
-   LICENSE_${PN}-accepts = "MIT"
-   LICENSE_${PN}-array-flatten = "MIT"
+   LICENSE:${PN} = "MIT"
+   LICENSE:${PN}-accepts = "MIT"
+   LICENSE:${PN}-array-flatten = "MIT"
    ...
-   LICENSE_${PN}-vary = "MIT"
+   LICENSE:${PN}-vary = "MIT"
 
 Here are three key points in the previous example:
 
@@ -7389,11 +7398,11 @@
 set it for a specific package type and/or package. Note that the order
 of precedence is the same as this list:
 
--  ``PACKAGE_ADD_METADATA_<PKGTYPE>_<PN>``
+-  ``PACKAGE_ADD_METADATA_<PKGTYPE>:<PN>``
 
 -  ``PACKAGE_ADD_METADATA_<PKGTYPE>``
 
--  ``PACKAGE_ADD_METADATA_<PN>``
+-  ``PACKAGE_ADD_METADATA:<PN>``
 
 -  :term:`PACKAGE_ADD_METADATA`
 
@@ -7523,7 +7532,7 @@
 
 Set these variables in your distribution configuration file as follows::
 
-   DISTRO_FEATURES_append = " systemd"
+   DISTRO_FEATURES:append = " systemd"
    VIRTUAL-RUNTIME_init_manager = "systemd"
 
 You can also prevent the SysVinit distribution feature from
@@ -7547,7 +7556,7 @@
 
 Set these variables in your distribution configuration file as follows::
 
-   DISTRO_FEATURES_append = " systemd"
+   DISTRO_FEATURES:append = " systemd"
    VIRTUAL-RUNTIME_init_manager = "systemd"
 
 Doing so causes your main image to use the
@@ -7646,7 +7655,7 @@
 Then, you can add the following to your
 ``local.conf``::
 
-   SRCREV_pn-PN = "${AUTOREV}"
+   SRCREV:pn-PN = "${AUTOREV}"
 
 :term:`PN` is the name of the recipe for
 which you want to enable automatic source revision updating.
@@ -7664,22 +7673,22 @@
 This line pulls in the
 listed include file that contains numerous lines of exactly that form::
 
-   #SRCREV_pn-opkg-native ?= "${AUTOREV}"
-   #SRCREV_pn-opkg-sdk ?= "${AUTOREV}"
-   #SRCREV_pn-opkg ?= "${AUTOREV}"
-   #SRCREV_pn-opkg-utils-native ?= "${AUTOREV}"
-   #SRCREV_pn-opkg-utils ?= "${AUTOREV}"
-   SRCREV_pn-gconf-dbus ?= "${AUTOREV}"
-   SRCREV_pn-matchbox-common ?= "${AUTOREV}"
-   SRCREV_pn-matchbox-config-gtk ?= "${AUTOREV}"
-   SRCREV_pn-matchbox-desktop ?= "${AUTOREV}"
-   SRCREV_pn-matchbox-keyboard ?= "${AUTOREV}"
-   SRCREV_pn-matchbox-panel-2 ?= "${AUTOREV}"
-   SRCREV_pn-matchbox-themes-extra ?= "${AUTOREV}"
-   SRCREV_pn-matchbox-terminal ?= "${AUTOREV}"
-   SRCREV_pn-matchbox-wm ?= "${AUTOREV}"
-   SRCREV_pn-settings-daemon ?= "${AUTOREV}"
-   SRCREV_pn-screenshot ?= "${AUTOREV}"
+   #SRCREV:pn-opkg-native ?= "${AUTOREV}"
+   #SRCREV:pn-opkg-sdk ?= "${AUTOREV}"
+   #SRCREV:pn-opkg ?= "${AUTOREV}"
+   #SRCREV:pn-opkg-utils-native ?= "${AUTOREV}"
+   #SRCREV:pn-opkg-utils ?= "${AUTOREV}"
+   SRCREV:pn-gconf-dbus ?= "${AUTOREV}"
+   SRCREV:pn-matchbox-common ?= "${AUTOREV}"
+   SRCREV:pn-matchbox-config-gtk ?= "${AUTOREV}"
+   SRCREV:pn-matchbox-desktop ?= "${AUTOREV}"
+   SRCREV:pn-matchbox-keyboard ?= "${AUTOREV}"
+   SRCREV:pn-matchbox-panel-2 ?= "${AUTOREV}"
+   SRCREV:pn-matchbox-themes-extra ?= "${AUTOREV}"
+   SRCREV:pn-matchbox-terminal ?= "${AUTOREV}"
+   SRCREV:pn-matchbox-wm ?= "${AUTOREV}"
+   SRCREV:pn-settings-daemon ?= "${AUTOREV}"
+   SRCREV:pn-screenshot ?= "${AUTOREV}"
    . . .
 
 These lines allow you to
@@ -7737,9 +7746,9 @@
 (``pkg_postinst``) scripts for packages that are installed into the
 image can be run at the time when the root filesystem is created during
 the build on the host system. These scripts cannot attempt to run during
-first-boot on the target device. With the "read-only-rootfs" feature
-enabled, the build system checks during root filesystem creation to make
-sure all post-installation scripts succeed. If any of these scripts
+the first boot on the target device. With the "read-only-rootfs" feature
+enabled, the build system makes sure that all post-installation scripts
+succeed at file system creation time. If any of these scripts
 still need to be run after the root filesystem is created, the build
 immediately fails. These build-time checks ensure that the build fails
 rather than the target device fails later during its initial boot
@@ -7922,25 +7931,25 @@
 
    $ buildhistory-collect-srcrevs -a
    # i586-poky-linux
-   SRCREV_pn-glibc = "b8079dd0d360648e4e8de48656c5c38972621072"
-   SRCREV_pn-glibc-initial = "b8079dd0d360648e4e8de48656c5c38972621072"
-   SRCREV_pn-opkg-utils = "53274f087565fd45d8452c5367997ba6a682a37a"
-   SRCREV_pn-kmod = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
+   SRCREV:pn-glibc = "b8079dd0d360648e4e8de48656c5c38972621072"
+   SRCREV:pn-glibc-initial = "b8079dd0d360648e4e8de48656c5c38972621072"
+   SRCREV:pn-opkg-utils = "53274f087565fd45d8452c5367997ba6a682a37a"
+   SRCREV:pn-kmod = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
    # x86_64-linux
-   SRCREV_pn-gtk-doc-stub-native = "1dea266593edb766d6d898c79451ef193eb17cfa"
-   SRCREV_pn-dtc-native = "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf"
-   SRCREV_pn-update-rc.d-native = "eca680ddf28d024954895f59a241a622dd575c11"
-   SRCREV_glibc_pn-cross-localedef-native = "b8079dd0d360648e4e8de48656c5c38972621072"
-   SRCREV_localedef_pn-cross-localedef-native = "c833367348d39dad7ba018990bfdaffaec8e9ed3"
-   SRCREV_pn-prelink-native = "faa069deec99bf61418d0bab831c83d7c1b797ca"
-   SRCREV_pn-opkg-utils-native = "53274f087565fd45d8452c5367997ba6a682a37a"
-   SRCREV_pn-kern-tools-native = "23345b8846fe4bd167efdf1bd8a1224b2ba9a5ff"
-   SRCREV_pn-kmod-native = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
+   SRCREV:pn-gtk-doc-stub-native = "1dea266593edb766d6d898c79451ef193eb17cfa"
+   SRCREV:pn-dtc-native = "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf"
+   SRCREV:pn-update-rc.d-native = "eca680ddf28d024954895f59a241a622dd575c11"
+   SRCREV_glibc:pn-cross-localedef-native = "b8079dd0d360648e4e8de48656c5c38972621072"
+   SRCREV_localedef:pn-cross-localedef-native = "c833367348d39dad7ba018990bfdaffaec8e9ed3"
+   SRCREV:pn-prelink-native = "faa069deec99bf61418d0bab831c83d7c1b797ca"
+   SRCREV:pn-opkg-utils-native = "53274f087565fd45d8452c5367997ba6a682a37a"
+   SRCREV:pn-kern-tools-native = "23345b8846fe4bd167efdf1bd8a1224b2ba9a5ff"
+   SRCREV:pn-kmod-native = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
    # qemux86-poky-linux
-   SRCREV_machine_pn-linux-yocto = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
-   SRCREV_meta_pn-linux-yocto = "a227f20eff056e511d504b2e490f3774ab260d6f"
+   SRCREV_machine:pn-linux-yocto = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
+   SRCREV_meta:pn-linux-yocto = "a227f20eff056e511d504b2e490f3774ab260d6f"
    # all-poky-linux
-   SRCREV_pn-update-rc.d = "eca680ddf28d024954895f59a241a622dd575c11"
+   SRCREV:pn-update-rc.d = "eca680ddf28d024954895f59a241a622dd575c11"
 
 .. note::
 
@@ -8564,11 +8573,11 @@
 
 -  The default tests for the image are defined as::
 
-      DEFAULT_TEST_SUITES_pn-image = "ping ssh df connman syslog xorg scp vnc date rpm dnf dmesg"
+      DEFAULT_TEST_SUITES:pn-image = "ping ssh df connman syslog xorg scp vnc date rpm dnf dmesg"
 
 -  Add your own test to the list of the by using the following::
 
-      TEST_SUITES_append = " mytest"
+      TEST_SUITES:append = " mytest"
 
 -  Run a specific list of tests as follows::
 
@@ -8941,7 +8950,7 @@
 -  After the variable values, all functions appear in the output. For
    shell functions, variables referenced within the function body are
    expanded. If a function has been modified using overrides or using
-   override-style operators like ``_append`` and ``_prepend``, then the
+   override-style operators like ``:append`` and ``:prepend``, then the
    final assembled function body appears in the output.
 
 Viewing Package Information with ``oe-pkgdata-util``
@@ -9715,7 +9724,7 @@
    (it already is in ``OpenEmbedded-core`` defaults and ``poky`` reference distribution).
    If not, set in your distro config file or in ``local.conf``::
 
-      DISTRO_FEATURES_append = " debuginfod"
+      DISTRO_FEATURES:append = " debuginfod"
 
    This distro feature enables the server and client library in ``elfutils``,
    and enables ``debuginfod`` support in clients (at the moment, ``gdb`` and ``binutils``).
@@ -9802,7 +9811,7 @@
    Make the following addition in either your ``local.conf`` file or in
    an image recipe::
 
-      IMAGE_INSTALL_append = " gdbserver"
+      IMAGE_INSTALL:append = " gdbserver"
 
    The change makes
    sure the ``gdbserver`` package is included.
@@ -9938,21 +9947,21 @@
 -  Ensure that GDB is on the target. You can do this by adding "gdb" to
    :term:`IMAGE_INSTALL`::
 
-      IMAGE_INSTALL_append = " gdb"
+      IMAGE_INSTALL:append = " gdb"
 
    Alternatively, you can add "tools-debug" to :term:`IMAGE_FEATURES`::
 
-      IMAGE_FEATURES_append = " tools-debug"
+      IMAGE_FEATURES:append = " tools-debug"
 
 -  Ensure that debug symbols are present. You can make sure these
    symbols are present by installing ``-dbg``::
 
-      IMAGE_INSTALL_append = "packagename-dbg"
+      IMAGE_INSTALL:append = "packagename-dbg"
 
    Alternatively, you can do the following to include
    all the debug symbols::
 
-      IMAGE_FEATURES_append = " dbg-pkgs"
+      IMAGE_FEATURES:append = " dbg-pkgs"
 
 .. note::
 
@@ -11131,6 +11140,75 @@
 The :term:`CVE_PRODUCT` variable defines the name used to match the recipe name
 against the name in the upstream `NIST CVE database <https://nvd.nist.gov/>`__.
 
+Editing recipes to fix vulnerabilities
+--------------------------------------
+
+To fix a given known vulnerability, you need to add a patch file to your recipe. Here's
+an example from the :oe_layerindex:`ffmpeg recipe</layerindex/recipe/47350>`::
+
+   SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
+              file://0001-libavutil-include-assembly-with-full-path-from-sourc.patch \
+              file://fix-CVE-2020-20446.patch \
+              file://fix-CVE-2020-20453.patch \
+              file://fix-CVE-2020-22015.patch \
+              file://fix-CVE-2020-22021.patch \
+              file://fix-CVE-2020-22033-CVE-2020-22019.patch \
+              file://fix-CVE-2021-33815.patch \
+
+The :ref:`cve-check <ref-classes-cve-check>` class defines two ways of
+supplying a patch for a given CVE. The first
+way is to use a patch filename that matches the below pattern::
+
+   cve_file_name_match = re.compile(".*([Cc][Vv][Ee]\-\d{4}\-\d+)")
+
+As shown in the example above, multiple CVE IDs can appear in a patch filename,
+but the :ref:`cve-check <ref-classes-cve-check>` class will only consider
+the last CVE ID in the filename as patched.
+
+The second way to recognize a patched CVE ID is when a line matching the
+below pattern is found in any patch file provided by the recipe::
+
+  cve_match = re.compile("CVE:( CVE\-\d{4}\-\d+)+")
+
+This allows a single patch file to address multiple CVE IDs at the same time.
+
+Of course, another way to fix vulnerabilities is to upgrade to a version
+of the package which is not impacted, typically a more recent one.
+The NIST database knows which versions are vulnerable and which ones
+are not.
+
+Last but not least, you can choose to ignore vulnerabilities through
+the :term:`CVE_CHECK_PN_WHITELIST` and :term:`CVE_CHECK_WHITELIST`
+variables.
+
+Implementation details
+----------------------
+
+Here's what the :ref:`cve-check <ref-classes-cve-check>` class does to
+find unpatched CVE IDs.
+
+First the code goes through each patch file provided by a recipe. If a valid CVE ID
+is found in the name of the file, the corresponding CVE is considered as patched.
+Don't forget that if multiple CVE IDs are found in the filename, only the last
+one is considered. Then, the code looks for ``CVE: CVE-ID`` lines in the patch
+file. The found CVE IDs are also considered as patched.
+
+Then, the code looks up all the CVE IDs in the NIST database for all the
+products defined in :term:`CVE_PRODUCT`. Then, for each found CVE:
+
+ - If the package name (:term:`PN`) is part of
+   :term:`CVE_CHECK_PN_WHITELIST`, it is considered as patched.
+
+ - If the CVE ID is part of :term:`CVE_CHECK_WHITELIST`, it is
+   considered as patched too.
+
+ - If the CVE ID is part of the patched CVE for the recipe, it is
+   already considered as patched.
+
+ - Otherwise, the code checks whether the recipe version (:term:`PV`)
+   is within the range of versions impacted by the CVE. If so, the CVE
+   is considered as unpatched.
+
 The CVE database is stored in :term:`DL_DIR` and can be inspected using
 ``sqlite3`` command as follows::
 
@@ -11274,7 +11352,7 @@
 :term:`DISTRO_FEATURES`
 statement in your ``local.conf`` file::
 
-   DISTRO_FEATURES_append = " wayland"
+   DISTRO_FEATURES:append = " wayland"
 
 .. note::
 
diff --git a/poky/documentation/kernel-dev/advanced.rst b/poky/documentation/kernel-dev/advanced.rst
index 871ec8a..2dbcca6 100644
--- a/poky/documentation/kernel-dev/advanced.rst
+++ b/poky/documentation/kernel-dev/advanced.rst
@@ -69,7 +69,7 @@
    You can use the :term:`KBRANCH` value to define an alternate branch typically
    with a machine override as shown here from the ``meta-yocto-bsp`` layer::
 
-           KBRANCH_edgerouter = "standard/edgerouter"
+           KBRANCH:edgerouter = "standard/edgerouter"
 
 
 The linux-yocto style recipes can optionally define the following
@@ -113,7 +113,7 @@
 feature called "cfg/sound.scc" just for the ``qemux86`` machine,
 specify::
 
-   KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc"
+   KERNEL_FEATURES:append:qemux86 = " cfg/sound.scc"
 
 The value of
 the entries in :term:`KERNEL_FEATURES` are dependent on their location
@@ -724,7 +724,7 @@
 ``*.scc`` in the :term:`SRC_URI` statement. You need to use the following
 form from your kernel append file::
 
-   SRC_URI_append_myplatform = " \
+   SRC_URI:append:myplatform = " \
        file://myplatform;type=kmeta;destsuffix=myplatform \
        "
 
diff --git a/poky/documentation/kernel-dev/common.rst b/poky/documentation/kernel-dev/common.rst
index a97140b..d42ca5f 100644
--- a/poky/documentation/kernel-dev/common.rst
+++ b/poky/documentation/kernel-dev/common.rst
@@ -416,16 +416,16 @@
    kernel. Thus, the name of the append file is
    ``linux-yocto_4.12.bbappend``::
 
-      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+      FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
 
-      SRC_URI_append = " file://patch-file-one.patch"
-      SRC_URI_append = " file://patch-file-two.patch"
-      SRC_URI_append = " file://patch-file-three.patch"
+      SRC_URI:append = " file://patch-file-one.patch"
+      SRC_URI:append = " file://patch-file-two.patch"
+      SRC_URI:append = " file://patch-file-three.patch"
 
    The :term:`FILESEXTRAPATHS` and :term:`SRC_URI` statements
    enable the OpenEmbedded build system to find patch files. For more
    information on using append files, see the
-   ":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
+   ":ref:`dev-manual/common-tasks:appending other layers metadata with your layer`"
    section in the Yocto Project Development Tasks Manual.
 
 Modifying an Existing Recipe
@@ -469,7 +469,7 @@
 :term:`FILESEXTRAPATHS`
 variable as follows::
 
-   FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+   FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
 
 The path ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``
 expands to "linux-yocto" in the current directory for this example. If
@@ -496,29 +496,29 @@
 strings in the file from the ``meta-yocto-bsp`` layer upstream.
 ::
 
-   KBRANCH_genericx86  = "standard/base"
-   KBRANCH_genericx86-64  = "standard/base"
+   KBRANCH:genericx86  = "standard/base"
+   KBRANCH:genericx86-64  = "standard/base"
 
-   KMACHINE_genericx86 ?= "common-pc"
-   KMACHINE_genericx86-64 ?= "common-pc-64"
-   KBRANCH_edgerouter = "standard/edgerouter"
-   KBRANCH_beaglebone = "standard/beaglebone"
+   KMACHINE:genericx86 ?= "common-pc"
+   KMACHINE:genericx86-64 ?= "common-pc-64"
+   KBRANCH:edgerouter = "standard/edgerouter"
+   KBRANCH:beaglebone = "standard/beaglebone"
 
-   SRCREV_machine_genericx86    ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19"
-   SRCREV_machine_genericx86-64 ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19"
-   SRCREV_machine_edgerouter ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d"
-   SRCREV_machine_beaglebone ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d"
+   SRCREV_machine:genericx86    ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19"
+   SRCREV_machine:genericx86-64 ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19"
+   SRCREV_machine:edgerouter ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d"
+   SRCREV_machine:beaglebone ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d"
 
 
-   COMPATIBLE_MACHINE_genericx86 = "genericx86"
-   COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
-   COMPATIBLE_MACHINE_edgerouter = "edgerouter"
-   COMPATIBLE_MACHINE_beaglebone = "beaglebone"
+   COMPATIBLE_MACHINE:genericx86 = "genericx86"
+   COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
+   COMPATIBLE_MACHINE:edgerouter = "edgerouter"
+   COMPATIBLE_MACHINE:beaglebone = "beaglebone"
 
-   LINUX_VERSION_genericx86 = "4.12.7"
-   LINUX_VERSION_genericx86-64 = "4.12.7"
-   LINUX_VERSION_edgerouter = "4.12.10"
-   LINUX_VERSION_beaglebone = "4.12.10"
+   LINUX_VERSION:genericx86 = "4.12.7"
+   LINUX_VERSION:genericx86-64 = "4.12.7"
+   LINUX_VERSION:edgerouter = "4.12.10"
+   LINUX_VERSION:beaglebone = "4.12.10"
 
 This append file
 contains statements used to support several BSPs that ship with the
@@ -640,7 +640,7 @@
 directory, and rename the copied file to "defconfig". Then, add the
 following lines to the linux-yocto ``.bbappend`` file in your layer::
 
-   FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+   FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
    SRC_URI += "file://defconfig"
 
 The :term:`SRC_URI` tells the build system how to search
@@ -687,7 +687,7 @@
 configuration fragment and extend the :term:`FILESPATH` variable in your
 ``.bbappend`` file::
 
-   FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+   FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
    SRC_URI += "file://8250.cfg"
 
 The next time you run BitBake to build the
@@ -726,7 +726,7 @@
 and provides the path to the "in-tree" ``defconfig`` file to be used for
 a Raspberry Pi 2, which is based on the Broadcom 2708/2709 chipset::
 
-   KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
+   KBUILD_DEFCONFIG:raspberrypi2 ?= "bcm2709_defconfig"
 
 Aside from modifying your kernel recipe and providing your own
 ``defconfig`` file, you need to be sure no files or statements set
@@ -988,10 +988,10 @@
 
    Add the following to the ``local.conf``::
 
-      SRC_URI_pn-linux-yocto = "git:///path-to/linux-yocto-4.12;protocol=file;name=machine;branch=standard/base; \
+      SRC_URI:pn-linux-yocto = "git:///path-to/linux-yocto-4.12;protocol=file;name=machine;branch=standard/base; \
                                 git:///path-to/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}"
-      SRCREV_meta_qemux86 = "${AUTOREV}"
-      SRCREV_machine_qemux86 = "${AUTOREV}"
+      SRCREV_meta:qemux86 = "${AUTOREV}"
+      SRCREV_machine:qemux86 = "${AUTOREV}"
 
    .. note::
 
@@ -1061,8 +1061,8 @@
    must be named ``linux-yocto_4.12.bbappend`` and have the following
    contents::
 
-      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-      SRC_URI_append = "file://0001-calibrate.c-Added-some-printk-statements.patch"
+      FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
+      SRC_URI:append = "file://0001-calibrate.c-Added-some-printk-statements.patch"
 
    The :term:`FILESEXTRAPATHS` and :term:`SRC_URI` statements
    enable the OpenEmbedded build system to find the patch file.
@@ -1070,7 +1070,7 @@
    For more information on append files and patches, see the
    ":ref:`kernel-dev/common:creating the append file`" and
    ":ref:`kernel-dev/common:applying patches`" sections. You can also see the
-   ":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
+   ":ref:`dev-manual/common-tasks:appending other layers metadata with your layer`"
    section in the Yocto Project Development Tasks Manual.
 
    .. note::
@@ -1237,7 +1237,7 @@
 add the following lines to the linux-yocto ``.bbappend`` file in your
 layer::
 
-   FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+   FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
    SRC_URI += "file://defconfig"
 
 The :term:`SRC_URI` tells the build system how to search for the file, while the
@@ -1345,7 +1345,7 @@
 statements to the kernel's append file, those configuration options will
 be picked up and applied when the kernel is built::
 
-   FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+   FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
    SRC_URI += "file://myconfig.cfg"
 
 As mentioned earlier, you can group related configurations into multiple
@@ -1939,7 +1939,7 @@
 2. *Add the Feature File to SRC_URI:* Add the ``.scc`` file to the
    recipe's :term:`SRC_URI` statement::
 
-      SRC_URI_append = " file://test.scc"
+      SRC_URI:append = " file://test.scc"
 
    The leading space before the path is important as the path is
    appended to the existing path.
@@ -1948,7 +1948,7 @@
    :term:`KERNEL_FEATURES` statement to specify the feature as a kernel
    feature::
 
-      KERNEL_FEATURES_append = " test.scc"
+      KERNEL_FEATURES:append = " test.scc"
 
    The OpenEmbedded build
    system processes the kernel feature when it builds the kernel.
diff --git a/poky/documentation/kernel-dev/faq.rst b/poky/documentation/kernel-dev/faq.rst
index f0a7af3..5aa702a 100644
--- a/poky/documentation/kernel-dev/faq.rst
+++ b/poky/documentation/kernel-dev/faq.rst
@@ -36,9 +36,9 @@
 The kernel image (e.g. ``vmlinuz``) is provided by the
 ``kernel-image`` package. Image recipes depend on ``kernel-base``. To
 specify whether or not the kernel image is installed in the generated
-root filesystem, override ``RDEPENDS_${KERNEL_PACKAGE_NAME}-base`` to include or not
+root filesystem, override ``RDEPENDS:${KERNEL_PACKAGE_NAME}-base`` to include or not
 include "kernel-image". See the
-":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
+":ref:`dev-manual/common-tasks:appending other layers metadata with your layer`"
 section in the
 Yocto Project Development Tasks Manual for information on how to use an
 append file to override metadata.
diff --git a/poky/documentation/migration-guides/migration-1.4.rst b/poky/documentation/migration-guides/migration-1.4.rst
index 3f98091..baf3c08 100644
--- a/poky/documentation/migration-guides/migration-1.4.rst
+++ b/poky/documentation/migration-guides/migration-1.4.rst
@@ -83,7 +83,7 @@
 you can find in the :term:`Source Directory` at
 ``meta/recipes-core/init-ifupdown``. For information on how to use
 append files, see the
-":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
+":ref:`dev-manual/common-tasks:appending other layers metadata with your layer`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _migration-1.4-remote-debugging:
diff --git a/poky/documentation/migration-guides/migration-1.5.rst b/poky/documentation/migration-guides/migration-1.5.rst
index e1ba4a9..11c8212 100644
--- a/poky/documentation/migration-guides/migration-1.5.rst
+++ b/poky/documentation/migration-guides/migration-1.5.rst
@@ -144,7 +144,7 @@
 
 BitBake will now shorten revisions from Git repositories from the normal
 40 characters down to 10 characters within :term:`SRCPV`
-for improved usability in path and file names. This change should be
+for improved usability in path and filenames. This change should be
 safe within contexts where these revisions are used because the chances
 of spatially close collisions is very low. Distant collisions are not a
 major issue in the way the values are used.
diff --git a/poky/documentation/migration-guides/migration-3.4.rst b/poky/documentation/migration-guides/migration-3.4.rst
index 6fa1ab2..e83e936 100644
--- a/poky/documentation/migration-guides/migration-3.4.rst
+++ b/poky/documentation/migration-guides/migration-3.4.rst
@@ -56,6 +56,13 @@
 case where some code does use them as overrides but some does not. We plan to try
 and make the tune code use overrides more consistently in the future.
 
+There are some variables which do not use override syntax which include the
+suffix to variables in ``layer.conf`` files such as :term:`BBFILE_PATTERN`,
+:term:`SRCREV`\ ``_xxx`` where ``xxx`` is a name from :term:`SRC_URI` and
+:term:`PREFERRED_VERSION`\ ``_xxx``. In particular, ``layer.conf`` suffixes
+may be the same as a :term:`DISTRO` override causing some confusion. We do
+plan to try and improve consistency as these issues are identified.
+
 To help with migration of layers there is a script in OE-Core. Once configured
 with the overrides used by a layer, this can be run as::
 
diff --git a/poky/documentation/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst
index 4f8e6cb..c8b8988 100644
--- a/poky/documentation/overview-manual/concepts.rst
+++ b/poky/documentation/overview-manual/concepts.rst
@@ -1768,15 +1768,12 @@
 generators is to make some dependency and hash information available to
 the build. This information includes:
 
--  ``BB_BASEHASH_task-``\ taskname: The base hashes for each task in the
+-  ``BB_BASEHASH:task-``\ taskname: The base hashes for each task in the
    recipe.
 
 -  ``BB_BASEHASH_``\ filename\ ``:``\ taskname: The base hashes for each
    dependent task.
 
--  ``BBHASHDEPS_``\ filename\ ``:``\ taskname: The task dependencies for
-   each task.
-
 -  :term:`BB_TASKHASH`: The hash of the currently running task.
 
 Shared State
@@ -2027,7 +2024,7 @@
    .. note::
 
       By default, ``foo-dev`` also has an :term:`RDEPENDS`-style dependency on
-      ``foo``, because the default value of ``RDEPENDS_${PN}-dev`` (set in
+      ``foo``, because the default value of ``RDEPENDS:${PN}-dev`` (set in
       bitbake.conf) includes "${PN}".
 
    To ensure that the dependency chain is never broken, ``-dev`` and
diff --git a/poky/documentation/overview-manual/yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst
index d20a4ab..7aee9db 100644
--- a/poky/documentation/overview-manual/yp-intro.rst
+++ b/poky/documentation/overview-manual/yp-intro.rst
@@ -738,7 +738,7 @@
 defined by the classes it inherits from the OE-Core layer's class
 definitions in ``./meta/classes``. Within a recipe you can also define
 additional tasks as well as task prerequisites. Recipe syntax through
-BitBake also supports both ``_prepend`` and ``_append`` operators as a
+BitBake also supports both ``:prepend`` and ``:append`` operators as a
 method of extending task functionality. These operators inject code into
 the beginning or end of a task. For information on these BitBake
 operators, see the
diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst
index 49905f2..3af0238 100644
--- a/poky/documentation/ref-manual/classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -404,6 +404,22 @@
 section in the Yocto Project Overview and Concepts Manual for more
 discussion on these cross-compilation tools.
 
+.. _ref-classes-cve-check:
+
+``cve-check.bbclass``
+=====================
+
+The ``cve-check`` class looks for known CVEs (Common Vulnerabilities
+and Exposures) while building an image. This class is meant to be
+inherited globally from a configuration file::
+
+   INHERIT += "cve-check"
+
+You can also look for vulnerabilities in specific packages by passing
+``-c cve_check`` to BitBake. You will find details in the
+":ref:`dev-manual/common-tasks:checking for vulnerabilities`"
+section in the Development Tasks Manual.
+
 .. _ref-classes-debian:
 
 ``debian.bbclass``
@@ -456,8 +472,8 @@
 tarball. Following is an example::
 
    BBCLASSEXTEND = "devupstream:target"
-   SRC_URI_class-devupstream = "git://git.example.com/example"
-   SRCREV_class-devupstream = "abcd1234"
+   SRC_URI:class-devupstream = "git://git.example.com/example"
+   SRCREV:class-devupstream = "abcd1234"
 
 Adding the above statements to your recipe creates a variant that has
 :term:`DEFAULT_PREFERENCE` set to "-1".
@@ -465,8 +481,8 @@
 Any development-specific adjustments can be done by using the
 ``class-devupstream`` override. Here is an example::
 
-   DEPENDS_append_class-devupstream = " gperf-native"
-   do_configure_prepend_class-devupstream() {
+   DEPENDS:append:class-devupstream = " gperf-native"
+   do_configure:prepend:class-devupstream() {
        touch ${S}/README
    }
 
@@ -846,7 +862,7 @@
 inheriting the class, you can then disable the feature by setting the
 :term:`ICECC_DISABLED` variable to "1" as follows::
 
-   INHERIT_DISTRO_append = " icecc"
+   INHERIT_DISTRO:append = " icecc"
    ICECC_DISABLED ??= "1"
 
 This practice
@@ -974,7 +990,7 @@
 recipe, add the following to the recipe. You need to realize that the
 package name override, in this example ``${PN}``, must be used::
 
-   INSANE_SKIP_${PN} += "dev-so"
+   INSANE_SKIP:${PN} += "dev-so"
 
 Please keep in mind that the QA checks
 are meant to detect real or potential problems in the packaged
@@ -1182,7 +1198,7 @@
    its :term:`PN` value matches something already in :term:`OVERRIDES` (e.g.
    :term:`PN` happens to be the same as :term:`MACHINE` or
    :term:`DISTRO`), it can have unexpected consequences.
-   For example, assignments such as ``FILES_${PN} = "xyz"`` effectively
+   For example, assignments such as ``FILES:${PN} = "xyz"`` effectively
    turn into ``FILES = "xyz"``.
 
 -  ``rpaths:`` Checks for rpaths in the binaries that contain build
@@ -1208,7 +1224,7 @@
 
 -  ``unlisted-pkg-lics:`` Checks that all declared licenses applying
    for a package are also declared on the recipe level (i.e. any license
-   in ``LICENSE_*`` should appear in :term:`LICENSE`).
+   in ``LICENSE:*`` should appear in :term:`LICENSE`).
 
 -  ``useless-rpaths:`` Checks for dynamic library load paths (rpaths)
    in the binaries that by default on a standard system are searched by
@@ -1605,7 +1621,7 @@
       BBCLASSEXTEND = "native"
 
    Inside the
-   recipe, use ``_class-native`` and ``_class-target`` overrides to
+   recipe, use ``:class-native`` and ``:class-target`` overrides to
    specify any functionality specific to the respective native or target
    case.
 
@@ -1636,7 +1652,7 @@
        BBCLASSEXTEND = "nativesdk"
 
    Inside the
-   recipe, use ``_class-nativesdk`` and ``_class-target`` overrides to
+   recipe, use ``:class-nativesdk`` and ``:class-target`` overrides to
    specify any functionality specific to the respective SDK machine or
    target case.
 
@@ -2481,7 +2497,7 @@
 the recipe's main package, use ``${``\ :term:`PN`\ ``}``. Here
 is an example from the connman recipe::
 
-   SYSTEMD_SERVICE_${PN} = "connman.service"
+   SYSTEMD_SERVICE:${PN} = "connman.service"
 
 Services are set up to start on boot automatically
 unless you have set
diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst
index c7322e7..d3a603d 100644
--- a/poky/documentation/ref-manual/faq.rst
+++ b/poky/documentation/ref-manual/faq.rst
@@ -301,7 +301,7 @@
 attempt before any others by adding something like the following to the
 ``local.conf`` configuration file::
 
-   PREMIRRORS_prepend = "\
+   PREMIRRORS:prepend = "\
        git://.*/.* http://www.yoctoproject.org/sources/ \n \
        ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
        http://.*/.* http://www.yoctoproject.org/sources/ \n \
@@ -341,7 +341,7 @@
 You could make the following changes to the ``local.conf`` configuration
 file as long as the :term:`PREMIRRORS` server is current::
 
-   PREMIRRORS_prepend = "\
+   PREMIRRORS:prepend = "\
        ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
        http://.*/.* http://www.yoctoproject.org/sources/ \n \
        https://.*/.* http://www.yoctoproject.org/sources/ \n"
diff --git a/poky/documentation/ref-manual/kickstart.rst b/poky/documentation/ref-manual/kickstart.rst
index fc723cc..cac9f2f 100644
--- a/poky/documentation/ref-manual/kickstart.rst
+++ b/poky/documentation/ref-manual/kickstart.rst
@@ -65,13 +65,17 @@
 Here is a list that describes other supported options you can use with
 the ``part`` and ``partition`` commands:
 
--  ``--size``: The minimum partition size in MBytes. Specify an
-   integer value such as 500. Do not append the number with "MB". You do
-   not need this option if you use ``--source``.
+-  ``--size``: The minimum partition size. Specify as an integer value
+   optionally followed by one of the units "k" / "K" for kibibyte,
+   "M" for mebibyte and "G" for gibibyte. The default unit if none is
+   given is "M". You do not need this option if you use ``--source``.
 
--  ``--fixed-size``: The exact partition size in MBytes. You cannot
-   specify with ``--size``. An error occurs when assembling the disk
-   image if the partition data is larger than ``--fixed-size``.
+-  ``--fixed-size``: The exact partition size. Specify as an integer
+   value optionally followed by one of the units "k" / "K" for kibibyte,
+   "M" for mebibyte and "G" for gibibyte. The default unit if none is
+   given is "M".  Cannot be specify together with ``--size``. An error
+   occurs when assembling the disk image if the partition data is larger
+   than ``--fixed-size``.
 
 -  ``--source``: This option is a Wic-specific option that names the
    source of the data that populates the partition. The most common
@@ -134,10 +138,13 @@
 -  ``--align (in KBytes)``: This option is a Wic-specific option that
    says to start partitions on boundaries given x KBytes.
 
--  ``--offset (in KBytes)``: This option is a Wic-specific option that
+-  ``--offset``: This option is a Wic-specific option that
    says to place a partition at exactly the specified offset. If the
    partition cannot be placed at the specified offset, the image build
-   will fail.
+   will fail. Specify as an integer value optionally followed by one of
+   the units "s" / "S" for 512 byte sector, "k" / "K" for kibibyte, "M"
+   for mebibyte and "G" for gibibyte. The default unit if none is given
+   is "k".
 
 -  ``--no-table``: This option is a Wic-specific option. Using the
    option reserves space for the partition and causes it to become
@@ -151,7 +158,10 @@
 -  ``--extra-space``: This option is a Wic-specific option that adds
    extra space after the space filled by the content of the partition.
    The final size can exceed the size specified by the ``--size``
-   option. The default value is 10 Mbytes.
+   option. The default value is 10M. Specify as an integer value
+   optionally followed by one of the units "k" / "K" for kibibyte, "M"
+   for mebibyte and "G" for gibibyte. The default unit if none is given
+   is "M".
 
 -  ``--overhead-factor``: This option is a Wic-specific option that
    multiplies the size of the partition by the option's value. You must
diff --git a/poky/documentation/ref-manual/qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst
index 0ef203c..c3e40db 100644
--- a/poky/documentation/ref-manual/qa-checks.rst
+++ b/poky/documentation/ref-manual/qa-checks.rst
@@ -223,7 +223,7 @@
    software that reads :term:`CFLAGS` when you build it,
    you could add the following to your recipe::
 
-      CFLAGS_append = " -fPIC "
+      CFLAGS:append = " -fPIC "
 
    For more information on text relocations at runtime, see
    https://www.akkadia.org/drepper/textrelocs.html.
@@ -263,7 +263,7 @@
 
    The ``/usr/share/info/dir`` should not be packaged. Add the following
    line to your :ref:`ref-tasks-install` task or to your
-   ``do_install_append`` within the recipe as follows::
+   ``do_install:append`` within the recipe as follows::
 
       rm ${D}${infodir}/dir
    
@@ -347,7 +347,7 @@
     
 .. _qa-check-dep-cmp:
 
--  ``<var>_<packagename> is invalid: <comparison> (<value>)   only comparisons <, =, >, <=, and >= are allowed [dep-cmp]``
+-  ``<var>:<packagename> is invalid: <comparison> (<value>)   only comparisons <, =, >, <=, and >= are allowed [dep-cmp]``
 
    If you are adding a versioned dependency relationship to one of the
    dependency variables (:term:`RDEPENDS`,
@@ -454,14 +454,14 @@
    ``pkg_preinst``, ``pkg_postinst``, ``pkg_prerm``, ``pkg_postrm``, and
    :term:`ALLOW_EMPTY`) should always be set specific
    to a package (i.e. they should be set with a package name override
-   such as ``RDEPENDS_${PN} = "value"`` rather than
+   such as ``RDEPENDS:${PN} = "value"`` rather than
    ``RDEPENDS = "value"``). If you receive this error, correct any
    assignments to these variables within your recipe.
 
 
-- ``recipe uses DEPENDS_${PN}, should use DEPENDS [pkgvarcheck]``
+- ``recipe uses DEPENDS:${PN}, should use DEPENDS [pkgvarcheck]``
 
-   This check looks for instances of setting ``DEPENDS_${PN}``
+   This check looks for instances of setting ``DEPENDS:${PN}``
    which is erroneous (:term:`DEPENDS` is a recipe-wide variable and thus
    it is not correct to specify it for a particular package, nor will such
    an assignment actually work.) Set :term:`DEPENDS` instead.
@@ -524,7 +524,7 @@
    following:
 
    -  Add the files to :term:`FILES` for the package you want them to appear
-      in (e.g. ``FILES_${``\ :term:`PN`\ ``}`` for the main
+      in (e.g. ``FILES:${``\ :term:`PN`\ ``}`` for the main
       package).
 
    -  Delete the files at the end of the ``do_install`` task if the
@@ -539,18 +539,18 @@
    when a recipe has been renamed. However, if that is not the case, the
    message might indicate that a private version of a library is being
    erroneously picked up as the provider for a common library. If that
-   is the case, you should add the library's ``.so`` file name to
+   is the case, you should add the library's ``.so`` filename to
    :term:`PRIVATE_LIBS` in the recipe that provides
    the private version of the library.
 
 
 .. _qa-check-unlisted-pkg-lics:
 
--  ``LICENSE_<packagename> includes licenses (<licenses>) that are not listed in LICENSE [unlisted-pkg-lics]``
+-  ``LICENSE:<packagename> includes licenses (<licenses>) that are not listed in LICENSE [unlisted-pkg-lics]``
 
    The :term:`LICENSE` of the recipe should be a superset
    of all the licenses of all packages produced by this recipe. In other
-   words, any license in ``LICENSE_*`` should also appear in
+   words, any license in ``LICENSE:*`` should also appear in
    :term:`LICENSE`.
 
 
@@ -620,7 +620,7 @@
 
 .. _qa-check-missing-update-alternatives:
 
-- ``<recipename>: recipe defines ALTERNATIVE_<packagename> but doesn't inherit update-alternatives. This might fail during do_rootfs later! [missing-update-alternatives]``
+- ``<recipename>: recipe defines ALTERNATIVE:<packagename> but doesn't inherit update-alternatives. This might fail during do_rootfs later! [missing-update-alternatives]``
 
     This check ensures that if a recipe sets the :term:`ALTERNATIVE` variable that the
     recipe also inherits :ref:`update-alternatives <ref-classes-update-alternatives>` such
diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst
index 1150940..7aecda0 100644
--- a/poky/documentation/ref-manual/variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -38,9 +38,9 @@
       Like all package-controlling variables, you must always use them in
       conjunction with a package name override, as in::
 
-         ALLOW_EMPTY_${PN} = "1"
-         ALLOW_EMPTY_${PN}-dev = "1"
-         ALLOW_EMPTY_${PN}-staticdev = "1"
+         ALLOW_EMPTY:${PN} = "1"
+         ALLOW_EMPTY:${PN}-dev = "1"
+         ALLOW_EMPTY:${PN}-staticdev = "1"
 
    :term:`ALTERNATIVE`
       Lists commands in a package that need an alternative binary naming
@@ -53,7 +53,7 @@
       provided by another package. For example, if the ``busybox`` package
       has four such commands, you identify them as follows::
 
-         ALTERNATIVE_busybox = "sh sed test bracket"
+         ALTERNATIVE:busybox = "sh sed test bracket"
 
       For more information on the alternatives system, see the
       ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
@@ -297,7 +297,7 @@
       can attach it to a specific image recipe by using the recipe name
       override::
 
-         BAD_RECOMMENDATIONS_pn-target_image = "package_name"
+         BAD_RECOMMENDATIONS:pn-target_image = "package_name"
 
       It is important to realize that if you choose to not install packages
       using this variable and some other packages are dependent on them
@@ -575,7 +575,7 @@
 
          Internally, the :term:`BBCLASSEXTEND` mechanism generates recipe
          variants by rewriting variable values and applying overrides such
-         as ``_class-native``. For example, to generate a native version of
+         as ``:class-native``. For example, to generate a native version of
          a recipe, a :term:`DEPENDS` on "foo" is rewritten
          to a :term:`DEPENDS` on "foo-native".
 
@@ -1133,7 +1133,7 @@
       As an example, the following override allows you to install extra
       files, but only when building for the target::
 
-         do_install_append_class-target() {
+         do_install:append:class-target() {
              install my-extra-file ${D}${sysconfdir}
          }
 
@@ -1141,7 +1141,7 @@
       "native" when building for the build host, and to "other" when not
       building for the build host::
 
-         FOO_class-native = "native"
+         FOO:class-native = "native"
          FOO = "other"
 
       The underlying mechanism behind :term:`CLASSOVERRIDE` is simply
@@ -1246,7 +1246,7 @@
       that identifies the resulting package. Then, provide a
       space-separated list of files. Here is an example::
 
-         CONFFILES_${PN} += "${sysconfdir}/file1 \
+         CONFFILES:${PN} += "${sysconfdir}/file1 \
              ${sysconfdir}/file2 ${sysconfdir}/file3"
 
       There is a relationship between the :term:`CONFFILES` and :term:`FILES`
@@ -1471,11 +1471,22 @@
          variable only in certain contexts (e.g. when building for kernel
          and kernel module recipes).
 
+   :term:`CVE_CHECK_PN_WHITELIST`
+      The list of package names (:term:`PN`) for which
+      CVEs (Common Vulnerabilities and Exposures) are ignored.
+
+   :term:`CVE_CHECK_WHITELIST`
+      The list of CVE IDs which are ignored. Here is
+      an example from the :oe_layerindex:`Python3 recipe</layerindex/recipe/23823>`::
+
+         # This is windows only issue.
+         CVE_CHECK_WHITELIST += "CVE-2020-15523"
+
    :term:`CVE_PRODUCT`
       In a recipe, defines the name used to match the recipe name
       against the name in the upstream `NIST CVE database <https://nvd.nist.gov/>`__.
 
-      The default is ${:term:`BPN`}. If it does not match the name in NIST CVE
+      The default is ${:term:`BPN`}. If it does not match the name in the NIST CVE
       database or matches with multiple entries in the database, the default
       value needs to be changed.
 
@@ -1535,7 +1546,7 @@
       package naming. You must use the package name as an override when you
       set this variable. Here is an example from the ``fontconfig`` recipe::
 
-         DEBIAN_NOAUTONAME_fontconfig-utils = "1"
+         DEBIAN_NOAUTONAME:fontconfig-utils = "1"
 
    :term:`DEBIANNAME`
       When the :ref:`debian <ref-classes-debian>` class is inherited,
@@ -1545,7 +1556,7 @@
       override when you set this variable. Here is an example from the
       ``dbus`` recipe::
 
-         DEBIANNAME_${PN} = "dbus-1"
+         DEBIANNAME:${PN} = "dbus-1"
 
    :term:`DEBUG_BUILD`
       Specifies to build packages with debugging information. This
@@ -2104,7 +2115,7 @@
       to fix a runtime dependency to the exact same version of another
       package in the same recipe::
 
-         RDEPENDS_${PN}-additional-module = "${PN} (= ${EXTENDPKGV})"
+         RDEPENDS:${PN}-additional-module = "${PN} (= ${EXTENDPKGV})"
 
       The dependency relationships are intended to force the package
       manager to upgrade these types of packages in lock-step.
@@ -2204,7 +2215,7 @@
       this variable, use an override for the associated image type. Here is
       an example::
 
-         EXTRA_IMAGECMD_ext3 ?= "-i 4096"
+         EXTRA_IMAGECMD:ext3 ?= "-i 4096"
 
    :term:`EXTRA_IMAGEDEPENDS`
       A list of recipes to build that do not provide packages for
@@ -2331,7 +2342,7 @@
       list of files or paths that identify the files you want included as
       part of the resulting package. Here is an example::
 
-         FILES_${PN} += "${bindir}/mydir1 ${bindir}/mydir2/myfile"
+         FILES:${PN} += "${bindir}/mydir1 ${bindir}/mydir2/myfile"
 
       .. note::
 
@@ -2347,7 +2358,7 @@
             rather than ``/usr/bin``. You can find a list of these
             variables at the top of the ``meta/conf/bitbake.conf`` file in
             the :term:`Source Directory`. You will also
-            find the default values of the various ``FILES_*`` variables in
+            find the default values of the various ``FILES:*`` variables in
             this file.
 
       If some of the files you provide with the :term:`FILES` variable are
@@ -2380,7 +2391,7 @@
       :term:`FILESEXTRAPATHS` from within a ``.bbappend`` file and that you
       prepend paths as follows::
 
-         FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+         FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
 
       In the above example, the build system first
       looks for files in a directory that has the same name as the
@@ -2402,7 +2413,7 @@
 
       Here is another common use::
 
-         FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+         FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
 
       In this example, the build system extends the
       :term:`FILESPATH` variable to include a directory named ``files`` that is
@@ -2410,13 +2421,13 @@
 
       This next example specifically adds three paths::
 
-         FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
+         FILESEXTRAPATHS:prepend := "path_1:path_2:path_3:"
 
       A final example shows how you can extend the search path and include
       a :term:`MACHINE`-specific override, which is useful
       in a BSP layer::
 
-          FILESEXTRAPATHS_prepend_intel-x86-common := "${THISDIR}/${PN}:"
+          FILESEXTRAPATHS:prepend:intel-x86-common := "${THISDIR}/${PN}:"
 
       The previous statement appears in the
       ``linux-yocto-dev.bbappend`` file, which is found in the
@@ -2664,7 +2675,7 @@
 
       Here is an example from the ``dbus`` recipe::
 
-         GROUPADD_PARAM_${PN} = "-r netdev"
+         GROUPADD_PARAM:${PN} = "-r netdev"
 
       For information on the standard Linux shell command
       ``groupadd``, see https://linux.die.net/man/8/groupadd.
@@ -2977,7 +2988,7 @@
       ``btrfs``, and so forth). When setting this variable, you should use
       an override for the associated type. Here is an example::
 
-         IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime \
+         IMAGE_CMD:jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime \
              --output=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2 \
              ${EXTRA_IMAGECMD}"
 
@@ -3033,8 +3044,8 @@
             :term:`IMAGE_FSTYPES` prior to using the "inherit image" line.
 
          -  Due to the way the OpenEmbedded build system processes this
-            variable, you cannot update its contents by using ``_append``
-            or ``_prepend``. You must use the ``+=`` operator to add one or
+            variable, you cannot update its contents by using ``:append``
+            or ``:prepend``. You must use the ``+=`` operator to add one or
             more options to the :term:`IMAGE_FSTYPES` variable.
 
    :term:`IMAGE_INSTALL`
@@ -3052,7 +3063,7 @@
 
       When you use this variable, it is best to use it as follows::
 
-         IMAGE_INSTALL_append = " package-name"
+         IMAGE_INSTALL:append = " package-name"
 
       Be sure to include the space
       between the quotation character and the start of the package name or
@@ -3144,7 +3155,7 @@
          IMAGE_NAME ?= "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
 
    :term:`IMAGE_NAME_SUFFIX`
-      Suffix used for the image output file name - defaults to ``".rootfs"``
+      Suffix used for the image output filename - defaults to ``".rootfs"``
       to distinguish the image file from other files created during image
       building; however if this suffix is redundant or not desired you can
       clear the value of this variable (set the value to ""). For example,
@@ -3292,7 +3303,7 @@
       Specifies a dependency from one image type on another. Here is an
       example from the :ref:`image-live <ref-classes-image-live>` class::
 
-         IMAGE_TYPEDEP_live = "ext3"
+         IMAGE_TYPEDEP:live = "ext3"
 
       In the previous example, the variable ensures that when "live" is
       listed with the :term:`IMAGE_FSTYPES` variable,
@@ -3695,7 +3706,7 @@
       recipe. The package name override must be used, which in this example
       is ``${PN}``::
 
-         INSANE_SKIP_${PN} += "dev-so"
+         INSANE_SKIP:${PN} += "dev-so"
 
       See the ":ref:`insane.bbclass <ref-classes-insane>`" section for a
       list of the valid QA checks you can specify using this variable.
@@ -3749,10 +3760,10 @@
       ``meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend``.
       Here are the related statements from that append file::
 
-         KBRANCH_genericx86 = "standard/base"
-         KBRANCH_genericx86-64 = "standard/base"
-         KBRANCH_edgerouter = "standard/edgerouter"
-         KBRANCH_beaglebone = "standard/beaglebone"
+         KBRANCH:genericx86 = "standard/base"
+         KBRANCH:genericx86-64 = "standard/base"
+         KBRANCH:edgerouter = "standard/edgerouter"
+         KBRANCH:beaglebone = "standard/beaglebone"
 
       The :term:`KBRANCH` statements
       identify the kernel branch to use when building for each supported
@@ -3780,11 +3791,11 @@
       Here is an example from a "raspberrypi2" :term:`KMACHINE` build that uses
       a ``defconfig`` file named "bcm2709_defconfig"::
 
-         KBUILD_DEFCONFIG_raspberrypi2 = "bcm2709_defconfig"
+         KBUILD_DEFCONFIG:raspberrypi2 = "bcm2709_defconfig"
 
       As an alternative, you can use the following within your append file::
 
-         KBUILD_DEFCONFIG_pn-linux-yocto ?= defconfig_file
+         KBUILD_DEFCONFIG:pn-linux-yocto ?= "defconfig_file"
 
       For more
       information on how to use the :term:`KBUILD_DEFCONFIG` variable, see the
@@ -3932,10 +3943,10 @@
       statements add specific configurations to targeted machine types::
 
          KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc"
-         KERNEL_FEATURES_append = "${KERNEL_EXTRA_FEATURES}"
-         KERNEL_FEATURES_append_qemuall = "cfg/virtio.scc"
-         KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc"
-         KERNEL_FEATURES_append_qemux86-64 = "cfg/sound.scc"
+         KERNEL_FEATURES:append = "${KERNEL_EXTRA_FEATURES}"
+         KERNEL_FEATURES:append:qemuall = "cfg/virtio.scc"
+         KERNEL_FEATURES:append:qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc"
+         KERNEL_FEATURES:append:qemux86-64 = "cfg/sound.scc"
 
    :term:`KERNEL_FIT_LINK_NAME`
       The link name of the kernel flattened image tree (FIT) image. This
@@ -4117,13 +4128,13 @@
       Kernel's ``meta`` branch. As an example take a look in the
       ``common/recipes-kernel/linux/linux-yocto_3.19.bbappend`` file::
 
-         LINUX_VERSION_core2-32-intel-common = "3.19.0"
-         COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
-         SRCREV_meta_core2-32-intel-common = "8897ef68b30e7426bc1d39895e71fb155d694974"
-         SRCREV_machine_core2-32-intel-common = "43b9eced9ba8a57add36af07736344dcc383f711"
-         KMACHINE_core2-32-intel-common = "intel-core2-32"
-         KBRANCH_core2-32-intel-common = "standard/base"
-         KERNEL_FEATURES_append_core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}"
+         LINUX_VERSION:core2-32-intel-common = "3.19.0"
+         COMPATIBLE_MACHINE:core2-32-intel-common = "${MACHINE}"
+         SRCREV_meta:core2-32-intel-common = "8897ef68b30e7426bc1d39895e71fb155d694974"
+         SRCREV_machine:core2-32-intel-common = "43b9eced9ba8a57add36af07736344dcc383f711"
+         KMACHINE:core2-32-intel-common = "intel-core2-32"
+         KBRANCH:core2-32-intel-common = "standard/base"
+         KERNEL_FEATURES:append:core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}"
 
       The :term:`KMACHINE` statement says
       that the kernel understands the machine name as "intel-core2-32".
@@ -4303,15 +4314,15 @@
       Documentation License 1.2 could be specified as follows::
 
          LICENSE = "GFDL-1.2 & GPLv2"
-         LICENSE_${PN} = "GPLv2"
-         LICENSE_${PN}-doc = "GFDL-1.2"
+         LICENSE:${PN} = "GPLv2"
+         LICENSE:${PN}-doc = "GFDL-1.2"
 
    :term:`LICENSE_CREATE_PACKAGE`
       Setting :term:`LICENSE_CREATE_PACKAGE` to "1" causes the OpenEmbedded
       build system to create an extra package (i.e.
       ``${``\ :term:`PN`\ ``}-lic``) for each recipe and to add
       those packages to the
-      :term:`RRECOMMENDS`\ ``_${PN}``.
+      :term:`RRECOMMENDS`\ ``:${PN}``.
 
       The ``${PN}-lic`` package installs a directory in
       ``/usr/share/licenses`` named ``${PN}``, which is the recipe's base
@@ -4615,7 +4626,7 @@
       in QEMU, like in the following example from the ``connman-conf``
       recipe::
 
-         SRC_URI_append_qemuall = " file://wired.config \
+         SRC_URI:append:qemuall = " file://wired.config \
              file://wired-setup \
              "
 
@@ -4818,7 +4829,7 @@
       can attach it to a specific image recipe by using the recipe name
       override::
 
-         NO_RECOMMENDATIONS_pn-target_image = "1"
+         NO_RECOMMENDATIONS:pn-target_image = "1"
 
       It is important to realize that if you choose to not install packages
       using this variable and some other packages are dependent on them
@@ -4841,14 +4852,14 @@
 
    :term:`NOAUTOPACKAGEDEBUG`
       Disables auto package from splitting ``.debug`` files. If a recipe
-      requires ``FILES_${PN}-dbg`` to be set manually, the
+      requires ``FILES:${PN}-dbg`` to be set manually, the
       :term:`NOAUTOPACKAGEDEBUG` can be defined allowing you to define the
       content of the debug package. For example::
 
          NOAUTOPACKAGEDEBUG = "1"
-         FILES_${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*"
-         FILES_${PN}-dbg = "/usr/src/debug/"
-         FILES_${QT_BASE_NAME}-demos-doc = "${docdir}/${QT_DIR_NAME}/qch/qt.qch"
+         FILES:${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*"
+         FILES:${PN}-dbg = "/usr/src/debug/"
+         FILES:${QT_BASE_NAME}-demos-doc = "${docdir}/${QT_DIR_NAME}/qch/qt.qch"
 
    :term:`NON_MULTILIB_RECIPES`
       A list of recipes that should not be built for multilib. OE-Core's
@@ -4944,7 +4955,7 @@
       assignment will override ``FOO`` with the value "overridden" at the
       end of parsing::
 
-         FOO_an-override = "overridden"
+         FOO:an-override = "overridden"
 
       See the
       ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax (overrides)`"
@@ -4959,7 +4970,7 @@
       allows variables to be set for a single recipe within configuration
       (``.conf``) files. Here is an example::
 
-         FOO_pn-myrecipe = "myrecipe-specific value"
+         FOO:pn-myrecipe = "myrecipe-specific value"
 
       .. note::
 
@@ -5107,7 +5118,7 @@
       can attach it to a specific image recipe by using the recipe name
       override::
 
-         PACKAGE_EXCLUDE_pn-target_image = "package_name"
+         PACKAGE_EXCLUDE:pn-target_image = "package_name"
 
       If you choose to not install a package using this variable and some
       other package is dependent on it (i.e. listed in a recipe's
@@ -5344,18 +5355,18 @@
 
          Or, you can just append the variable::
 
-            PACKAGECONFIG_append = " f4"
+            PACKAGECONFIG:append = " f4"
 
       -  *Configuration file:* This method is identical to changing the
          block through an append file except you edit your ``local.conf``
          or ``mydistro.conf`` file. As with append files previously
          described, you can either completely override the variable::
 
-            PACKAGECONFIG_pn-recipename = "f4 f5"
+            PACKAGECONFIG:pn-recipename = "f4 f5"
 
          Or, you can just amend the variable::
 
-            PACKAGECONFIG_append_pn-recipename = " f4"
+            PACKAGECONFIG:append:pn-recipename = " f4"
 
    :term:`PACKAGECONFIG_CONFARGS`
       A space-separated list of configuration options generated from the
@@ -5390,7 +5401,7 @@
       (leftmost) package.
 
       Packages in the variable's list that are empty (i.e. where none of
-      the patterns in ``FILES_``\ pkg match any files installed by the
+      the patterns in ``FILES:``\ pkg match any files installed by the
       :ref:`ref-tasks-install` task) are not generated,
       unless generation is forced through the
       :term:`ALLOW_EMPTY` variable.
@@ -5541,7 +5552,7 @@
 
       For example, when the :ref:`debian <ref-classes-debian>` class
       renames the output package, it does so by setting
-      ``PKG_packagename``.
+      ``PKG:packagename``.
 
    :term:`PKG_CONFIG_PATH`
       The path to ``pkg-config`` files for the current build context.
@@ -5775,17 +5786,17 @@
       :term:`OVERRIDES` to set a machine-specific
       override. Here is an example::
 
-         PREFERRED_VERSION_linux-yocto_qemux86 = "5.0%"
+         PREFERRED_VERSION_linux-yocto:qemux86 = "5.0%"
 
       Although not recommended, worst case, you can also use the
       "forcevariable" override, which is the strongest override possible.
       Here is an example::
 
-         PREFERRED_VERSION_linux-yocto_forcevariable = "5.0%"
+         PREFERRED_VERSION_linux-yocto:forcevariable = "5.0%"
 
       .. note::
 
-         The ``\_forcevariable`` override is not handled specially. This override
+         The ``:forcevariable`` override is not handled specially. This override
          only works because the default value of :term:`OVERRIDES` includes "forcevariable".
 
       If a recipe with the specified version is not available, a warning
@@ -5809,7 +5820,7 @@
       the ``local.conf`` configuration file in the
       :term:`Build Directory`::
 
-         PREMIRRORS_prepend = "\
+         PREMIRRORS:prepend = "\
              git://.*/.* http://www.yoctoproject.org/sources/ \n \
              ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
              http://.*/.* http://www.yoctoproject.org/sources/ \n \
@@ -5992,7 +6003,7 @@
       Like all package-controlling variables, you must always use them in
       conjunction with a package name override. Here is an example::
 
-         RCONFLICTS_${PN} = "another_conflicting_package_name"
+         RCONFLICTS:${PN} = "another_conflicting_package_name"
 
       BitBake, which the OpenEmbedded build system uses, supports
       specifying versioned dependencies. Although the syntax varies
@@ -6000,7 +6011,7 @@
       from you. Here is the general syntax to specify versions with the
       :term:`RCONFLICTS` variable::
 
-         RCONFLICTS_${PN} = "package (operator version)"
+         RCONFLICTS:${PN} = "package (operator version)"
 
       For ``operator``, you can specify the following:
 
@@ -6013,7 +6024,7 @@
       For example, the following sets up a dependency on version 1.2 or
       greater of the package ``foo``::
 
-         RCONFLICTS_${PN} = "foo (>= 1.2)"
+         RCONFLICTS:${PN} = "foo (>= 1.2)"
 
    :term:`RDEPENDS`
       Lists runtime dependencies of a package. These dependencies are other
@@ -6022,7 +6033,7 @@
       package ``foo`` needs the packages ``bar`` and ``baz`` to be
       installed::
 
-         RDEPENDS_foo = "bar baz"
+         RDEPENDS:foo = "bar baz"
 
       The most common types of package
       runtime dependencies are automatically detected and added. Therefore,
@@ -6063,7 +6074,7 @@
       on the ``perl`` package. In this case, you would use the following
       :term:`RDEPENDS` statement::
 
-         RDEPENDS_${PN}-dev += "perl"
+         RDEPENDS:${PN}-dev += "perl"
 
       In the example,
       the development package depends on the ``perl`` package. Thus, the
@@ -6072,10 +6083,10 @@
 
       .. note::
 
-         ``RDEPENDS_${PN}-dev`` includes ``${``\ :term:`PN`\ ``}``
+         ``RDEPENDS:${PN}-dev`` includes ``${``\ :term:`PN`\ ``}``
          by default. This default is set in the BitBake configuration file
          (``meta/conf/bitbake.conf``). Be careful not to accidentally remove
-         ``${PN}`` when modifying ``RDEPENDS_${PN}-dev``. Use the "+=" operator
+         ``${PN}`` when modifying ``RDEPENDS:${PN}-dev``. Use the "+=" operator
          rather than the "=" operator.
 
       The package names you use with :term:`RDEPENDS` must appear as they would
@@ -6092,7 +6103,7 @@
       from you. Here is the general syntax to specify versions with the
       :term:`RDEPENDS` variable::
 
-         RDEPENDS_${PN} = "package (operator version)"
+         RDEPENDS:${PN} = "package (operator version)"
 
       For ``operator``, you can specify the following:
 
@@ -6112,7 +6123,7 @@
       For example, the following sets up a dependency on version 1.2 or
       greater of the package ``foo``::
 
-         RDEPENDS_${PN} = "foo (>= 1.2)"
+         RDEPENDS:${PN} = "foo (>= 1.2)"
 
       For information on build-time dependencies, see the
       :term:`DEPENDS` variable. You can also see the
@@ -6247,7 +6258,7 @@
       variable in conjunction with a package name override. Here is an
       example::
 
-         RPROVIDES_${PN} = "widget-abi-2"
+         RPROVIDES:${PN} = "widget-abi-2"
 
    :term:`RRECOMMENDS`
       A list of packages that extends the usability of a package being
@@ -6278,7 +6289,7 @@
       support wireless functionality. In this case, you would use the
       following::
 
-         RRECOMMENDS_${PN}-dev += "wireless_package_name"
+         RRECOMMENDS:${PN}-dev += "wireless_package_name"
 
       In the
       example, the package name (``${PN}-dev``) must appear as it would in
@@ -6291,7 +6302,7 @@
       Here is the general syntax to specify versions with the
       :term:`RRECOMMENDS` variable::
 
-         RRECOMMENDS_${PN} = "package (operator version)"
+         RRECOMMENDS:${PN} = "package (operator version)"
 
       For ``operator``, you can specify the following:
 
@@ -6304,7 +6315,7 @@
       For example, the following sets up a recommend on version 1.2 or
       greater of the package ``foo``::
 
-         RRECOMMENDS_${PN} = "foo (>= 1.2)"
+         RRECOMMENDS:${PN} = "foo (>= 1.2)"
 
    :term:`RREPLACES`
       A list of packages replaced by a package. The package manager uses
@@ -6316,7 +6327,7 @@
       As with all package-controlling variables, you must use this variable
       in conjunction with a package name override. Here is an example::
 
-         RREPLACES_${PN} = "other_package_being_replaced"
+         RREPLACES:${PN} = "other_package_being_replaced"
 
       BitBake, which the OpenEmbedded build system uses, supports
       specifying versioned replacements. Although the syntax varies
@@ -6324,7 +6335,7 @@
       from you. Here is the general syntax to specify versions with the
       :term:`RREPLACES` variable::
 
-         RREPLACES_${PN} = "package (operator version)"
+         RREPLACES:${PN} = "package (operator version)"
 
       For ``operator``, you can specify the following:
 
@@ -6337,7 +6348,7 @@
       For example, the following sets up a replacement using version 1.2
       or greater of the package ``foo``::
 
-          RREPLACES_${PN} = "foo (>= 1.2)"
+          RREPLACES:${PN} = "foo (>= 1.2)"
 
    :term:`RSUGGESTS`
       A list of additional packages that you can suggest for installation
@@ -6348,7 +6359,7 @@
       variable in conjunction with a package name override. Here is an
       example::
 
-         RSUGGESTS_${PN} = "useful_package another_package"
+         RSUGGESTS:${PN} = "useful_package another_package"
 
    :term:`S`
       The location in the :term:`Build Directory` where
@@ -6862,7 +6873,7 @@
       defined in the ``meta/conf/bitbake.conf`` configuration file.
 
       You will see this variable referenced in the default values of
-      ``FILES_${PN}``.
+      ``FILES:${PN}``.
 
    :term:`SOLIBSDEV`
       Defines the suffix for the development symbolic link (symlink) for
@@ -6871,7 +6882,7 @@
       ``meta/conf/bitbake.conf`` configuration file.
 
       You will see this variable referenced in the default values of
-      ``FILES_${PN}-dev``.
+      ``FILES:${PN}-dev``.
 
    :term:`SOURCE_MIRROR_FETCH`
       When you are fetching files to create a mirror of sources (i.e.
@@ -7609,7 +7620,7 @@
       override to indicate the package to which the value applies. Here is
       an example from the connman recipe::
 
-         SYSTEMD_SERVICE_${PN} = "connman.service"
+         SYSTEMD_SERVICE:${PN} = "connman.service"
 
    :term:`SYSVINIT_ENABLED_GETTYS`
       When using
@@ -7947,14 +7958,14 @@
       your own tests to the list of tests by appending :term:`TEST_SUITES` as
       follows::
 
-         TEST_SUITES_append = " mytest"
+         TEST_SUITES:append = " mytest"
 
       Alternatively, you can
       provide the "auto" option to have all applicable tests run against
       the image.
       ::
 
-         TEST_SUITES_append = " auto"
+         TEST_SUITES:append = " auto"
 
       Using this option causes the
       build system to automatically run tests that are applicable to the
@@ -8215,7 +8226,7 @@
       The BitBake configuration file (``meta/conf/bitbake.conf``) defines
       :term:`TUNE_FEATURES` as follows::
 
-         TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
+         TUNE_FEATURES ??= "${TUNE_FEATURES:tune-${DEFAULTTUNE}}"
 
       See the :term:`DEFAULTTUNE` variable for more information.
 
@@ -8241,13 +8252,13 @@
       the architecture, ABI, and tuning of output packages. The specific
       tune is defined using the "_tune" override as follows::
 
-         TUNE_PKGARCH_tune-tune = "tune"
+         TUNE_PKGARCH:tune-tune = "tune"
 
       These tune-specific package architectures are defined in the machine
       include files. Here is an example of the "core2-32" tuning as used in
       the ``meta/conf/machine/include/tune-core2.inc`` file::
 
-         TUNE_PKGARCH_tune-core2-32 = "core2-32"
+         TUNE_PKGARCH:tune-core2-32 = "core2-32"
 
    :term:`TUNEABI`
       An underlying Application Binary Interface (ABI) used by a particular
@@ -8614,7 +8625,7 @@
 
       Here is an example from the ``dbus`` recipe::
 
-         USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \
+         USERADD_PARAM:${PN} = "--system --home ${localstatedir}/lib/dbus \
                                 --no-create-home --shell /bin/false \
                                 --user-group messagebus"
 
diff --git a/poky/documentation/releases.rst b/poky/documentation/releases.rst
index 3ace7c0..3f96464 100644
--- a/poky/documentation/releases.rst
+++ b/poky/documentation/releases.rst
@@ -35,7 +35,8 @@
 - :yocto_docs:`3.1.6 Documentation </3.1.6>`
 - :yocto_docs:`3.1.7 Documentation </3.1.7>`
 - :yocto_docs:`3.1.8 Documentation </3.1.8>`
-- :yocto_docs:`3.1.8 Documentation </3.1.9>`
+- :yocto_docs:`3.1.9 Documentation </3.1.9>`
+- :yocto_docs:`3.1.10 Documentation </3.1.10>`
 
 ==========================
  Outdated Release Manuals
diff --git a/poky/documentation/sdk-manual/appendix-customizing-standard.rst b/poky/documentation/sdk-manual/appendix-customizing-standard.rst
index 9bc70cf..c619c15 100644
--- a/poky/documentation/sdk-manual/appendix-customizing-standard.rst
+++ b/poky/documentation/sdk-manual/appendix-customizing-standard.rst
@@ -29,6 +29,6 @@
 provided by recipes with the standard SDK by adding "api-documentation"
 to the
 :term:`DISTRO_FEATURES`
-variable: DISTRO_FEATURES_append = " api-documentation" Setting this
+variable: DISTRO_FEATURES:append = " api-documentation" Setting this
 variable as shown here causes the OpenEmbedded build system to build the
 documentation and then include it in the standard SDK.
diff --git a/poky/documentation/sdk-manual/appendix-customizing.rst b/poky/documentation/sdk-manual/appendix-customizing.rst
index 44f4334..4eccc28 100644
--- a/poky/documentation/sdk-manual/appendix-customizing.rst
+++ b/poky/documentation/sdk-manual/appendix-customizing.rst
@@ -73,7 +73,7 @@
       SDK_INHERIT_BLACKLIST
       is set using the "?=" operator. Consequently, you will need to
       either define the entire list by using the "=" operator, or you
-      will need to append a value using either "_append" or the "+="
+      will need to append a value using either ":append" or the "+="
       operator. You can learn more about these operators in the
       ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:basic syntax`"
       section of the BitBake User Manual.
@@ -250,7 +250,7 @@
       recipes that depend on lists of other recipes.
 
    -  Build the "world" target and set
-      ``EXCLUDE_FROM_WORLD_pn-``\ recipename for the recipes you do not
+      ``EXCLUDE_FROM_WORLD:pn-``\ recipename for the recipes you do not
       want built. See the
       :term:`EXCLUDE_FROM_WORLD`
       variable for additional information.
@@ -334,7 +334,7 @@
 time significantly and increases the size of the SDK installer by 30-80
 Mbytes depending on how many recipes are included in your configuration.
 
-You can use ``EXCLUDE_FROM_WORLD_pn-``\ recipename for recipes you want
+You can use ``EXCLUDE_FROM_WORLD:pn-``\ recipename for recipes you want
 to exclude. However, it is assumed that you would need to be building
 the "world" target if you want to provide additional items to the SDK.
 Consequently, building for "world" should not represent undue overhead
diff --git a/poky/documentation/sdk-manual/appendix-obtain.rst b/poky/documentation/sdk-manual/appendix-obtain.rst
index fc6b8b9..841abac 100644
--- a/poky/documentation/sdk-manual/appendix-obtain.rst
+++ b/poky/documentation/sdk-manual/appendix-obtain.rst
@@ -163,7 +163,7 @@
          SDK installer. Doing so ensures that the eventual SDK
          installation process installs the appropriate library packages
          as part of the SDK. Following is an example using ``libc``
-         static development libraries: TOOLCHAIN_TARGET_TASK_append = "
+         static development libraries: TOOLCHAIN_TARGET_TASK:append = "
          libc-staticdev"
 
 7. *Run the Installer:* You can now run the SDK installer from
diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst
index 2cdb06d..8ef44e3 100644
--- a/poky/documentation/sdk-manual/extensible.rst
+++ b/poky/documentation/sdk-manual/extensible.rst
@@ -838,7 +838,7 @@
 If you need to add runtime dependencies, you can do so by adding the
 following to your recipe::
 
-   RDEPENDS_${PN} += "dependency1 dependency2 ..."
+   RDEPENDS:${PN} += "dependency1 dependency2 ..."
 
 .. note::
 
@@ -1154,7 +1154,7 @@
 splitting. The :term:`PACKAGES` variable lists all of the packages to be
 produced, while the :term:`FILES` variable specifies which files to include
 in each package by using an override to specify the package. For
-example, ``FILES_${PN}`` specifies the files to go into the main package
+example, ``FILES:${PN}`` specifies the files to go into the main package
 (i.e. the main package has the same name as the recipe and
 ``${``\ :term:`PN`\ ``}`` evaluates to the
 recipe name). The order of the :term:`PACKAGES` value is significant. For
diff --git a/poky/documentation/sdk-manual/intro.rst b/poky/documentation/sdk-manual/intro.rst
index 2f94aaf..802d3f3 100644
--- a/poky/documentation/sdk-manual/intro.rst
+++ b/poky/documentation/sdk-manual/intro.rst
@@ -12,16 +12,6 @@
 explains how to use both the Yocto Project extensible and standard
 SDKs to develop applications and images.
 
-.. note::
-
-   Prior to the 2.0 Release of the Yocto Project, application
-   development was primarily accomplished through the use of the
-   Application Development Toolkit (ADT) and the availability of
-   stand-alone cross-development toolchains and other tools. With the
-   2.1 Release of the Yocto Project, application development has
-   transitioned to within a tool-rich extensible SDK and the more
-   traditional standard SDK.
-
 All SDKs consist of the following:
 
 -  *Cross-Development Toolchain*: This toolchain contains a compiler,
diff --git a/poky/documentation/sphinx-static/switchers.js b/poky/documentation/sphinx-static/switchers.js
index 3972b48..6243724 100644
--- a/poky/documentation/sphinx-static/switchers.js
+++ b/poky/documentation/sphinx-static/switchers.js
@@ -5,7 +5,7 @@
     'dev': 'dev (3.4)',
     '3.3.2': '3.3.2',
     '3.2.4': '3.2.4',
-    '3.1.9': '3.1.9',
+    '3.1.10': '3.1.10',
     '3.0.4': '3.0.4',
     '2.7.4': '2.7.4',
   };
diff --git a/poky/documentation/test-manual/reproducible-builds.rst b/poky/documentation/test-manual/reproducible-builds.rst
index c66c82f..68fdf54 100644
--- a/poky/documentation/test-manual/reproducible-builds.rst
+++ b/poky/documentation/test-manual/reproducible-builds.rst
@@ -70,7 +70,7 @@
 
 .. note::
 
-   Because of an open bug in GCC, using ``DISTRO_FEATURES_append = " lto"`` or
+   Because of an open bug in GCC, using ``DISTRO_FEATURES:append = " lto"`` or
    adding ``-flto`` (Link Time Optimization) to ``CFLAGS`` makes the resulting
    binary non-reproducible, in that it depends on the full absolute build path
    to ``recipe-sysroot-native``, so installing the Yocto Project in a different
diff --git a/poky/documentation/test-manual/understand-autobuilder.rst b/poky/documentation/test-manual/understand-autobuilder.rst
index c158d9c..b6809ce 100644
--- a/poky/documentation/test-manual/understand-autobuilder.rst
+++ b/poky/documentation/test-manual/understand-autobuilder.rst
@@ -27,7 +27,7 @@
          "TEMPLATE" : "arch-qemu",
          "step1" : {
                "extravars" : [
-                     "IMAGE_FSTYPES_append = ' wic wic.bmap'"
+                     "IMAGE_FSTYPES:append = ' wic wic.bmap'"
                     ]
         }
    },
diff --git a/poky/documentation/test-manual/yocto-project-compatible.rst b/poky/documentation/test-manual/yocto-project-compatible.rst
index a789746..96c12ac 100644
--- a/poky/documentation/test-manual/yocto-project-compatible.rst
+++ b/poky/documentation/test-manual/yocto-project-compatible.rst
@@ -115,6 +115,11 @@
    user changes a configuration setting to activate the layer, by selecting
    a :term:`MACHINE`, a :term:`DISTRO` or a :term:`DISTRO_FEATURES` setting.
 
+-  Layers should be documenting where they don’t support normal "core"
+   functionality such as where debug symbols are disabled or missing, where
+   development headers and on-target library usage may not work or where
+   functionality like the SDK/eSDK would not be expected to work.
+
 The project does test the compatibility status of the core project layers on
 its :doc:`Autobuilder </test-manual/understand-autobuilder>`.