diff --git a/docs/INSTALL.md b/docs/INSTALL.md
index 72b8c526eb..a80bee6c61 100644
--- a/docs/INSTALL.md
+++ b/docs/INSTALL.md
@@ -25,7 +25,7 @@ chmod u+x kustomize
 
 Requires [Go] v1.12 or higher:
 
-<!-- @installkustomize @test -->
+<!-- @installkustomize @testAgainstLatestRelease -->
 ```
 go install sigs.k8s.io/kustomize/v3/cmd/kustomize
 ```
diff --git a/docs/zh/INSTALL.md b/docs/zh/INSTALL.md
index f5a0bea4c8..98d84ede00 100644
--- a/docs/zh/INSTALL.md
+++ b/docs/zh/INSTALL.md
@@ -33,7 +33,7 @@ chmod u+x kustomize
 
 使用 [Go] v1.10.1 或更高版本安装（如果可以访问 [golang.org]）：
 
-<!-- @installkustomize @test -->
+<!-- @installkustomize @testAgainstLatestRelease -->
 ```
 go install sigs.k8s.io/kustomize/v3/cmd/kustomize
 ```
diff --git a/examples/README.md b/examples/README.md
index 559e3460e9..9a73adf602 100644
--- a/examples/README.md
+++ b/examples/README.md
@@ -2,15 +2,11 @@ English | [简体中文](zh/README.md)
 
 # Examples
 
-These examples assume that `kustomize` is on your `$PATH`.
+To run these examples, your `$PATH` must contain `kustomize`.
+See the [installation instructions](../docs/INSTALL.md).
 
-They are covered by [pre-commit](../travis/pre-commit.sh)
-tests, and should work with HEAD
-
-<!-- @installkustomize @test -->
-```
-go get sigs.k8s.io/kustomize/v3/cmd/kustomize
-```
+These examples are [tested](../travis/pre-commit.sh)
+to work with the latest _released_ version of kustomize.
 
 Basic Usage
 
@@ -71,4 +67,4 @@ Multi Variant Examples
   * [breakfast](breakfast.md) - Customize breakfast for
      Alice and Bob.
      
-  * [multibases](multibases/README.md) - Composing three variants (dev, staging, production) with a common base.  
\ No newline at end of file
+  * [multibases](multibases/README.md) - Composing three variants (dev, staging, production) with a common base.  
diff --git a/examples/breakfast.md b/examples/breakfast.md
index c36231c76d..d392370825 100644
--- a/examples/breakfast.md
+++ b/examples/breakfast.md
@@ -6,14 +6,14 @@
 
 Define a place to work:
 
-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
 
 Make a place to put the base breakfast configuration:
 
-<!-- @baseDir @test -->
+<!-- @baseDir @testAgainstLatestRelease -->
 ```
 mkdir -p $DEMO_HOME/breakfast/base
 ```
@@ -21,7 +21,7 @@ mkdir -p $DEMO_HOME/breakfast/base
 Make a `kustomization` to define what goes into
 breakfast.  This breakfast has coffee and pancakes:
 
-<!-- @baseKustomization @test -->
+<!-- @baseKustomization @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/breakfast/base/kustomization.yaml
 resources:
@@ -34,7 +34,7 @@ Here's a _coffee_ type.  Give it a `kind` and `metdata/name` field
 to conform to [kubernetes API object style]; no other
 file or definition is needed:
 
-<!-- @coffee @test -->
+<!-- @coffee @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/breakfast/base/coffee.yaml
 kind: Coffee
@@ -50,7 +50,7 @@ The `name` field merely distinguishes this instance of
 coffee from others (if there were any).
 
 Likewise, define _pancakes_:
-<!-- @pancakes @test -->
+<!-- @pancakes @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/breakfast/base/pancakes.yaml
 kind: Pancakes
@@ -64,7 +64,7 @@ EOF
 Make a custom [variant] of breakfast for Alice, who
 likes her coffee hot:
 
-<!-- @aliceOverlay @test -->
+<!-- @aliceOverlay @testAgainstLatestRelease -->
 ```
 mkdir -p $DEMO_HOME/breakfast/overlays/alice
 
@@ -87,7 +87,7 @@ EOF
 
 And likewise a [variant] for Bob, who wants _five_ pancakes, with strawberries:
 
-<!-- @bobOverlay @test -->
+<!-- @bobOverlay @testAgainstLatestRelease -->
 ```
 mkdir -p $DEMO_HOME/breakfast/overlays/bob
 
@@ -111,14 +111,14 @@ EOF
 
 One can now generate the configs for Alice’s breakfast:
 
-<!-- @generateAlice @test -->
+<!-- @generateAlice @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME/breakfast/overlays/alice
 ```
 
 Likewise for Bob:
 
-<!-- @generateBob @test -->
+<!-- @generateBob @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME/breakfast/overlays/bob
 ```
diff --git a/examples/combineConfigs.md b/examples/combineConfigs.md
index 251d01ebe8..ab2f310e74 100644
--- a/examples/combineConfigs.md
+++ b/examples/combineConfigs.md
@@ -128,7 +128,7 @@ defined in the [helloworld] demo.
 
 It will all live in this work directory:
 
-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -139,7 +139,7 @@ DEMO_HOME=$(mktemp -d)
 
 Make a place to put the base configuration:
 
-<!-- @baseDir @test -->
+<!-- @baseDir @testAgainstLatestRelease -->
 ```
 mkdir -p $DEMO_HOME/base
 ```
@@ -150,7 +150,7 @@ environments. Here we're only defining a java
 properties file, and a `kustomization` file that
 references it.
 
-<!-- @baseKustomization @test -->
+<!-- @baseKustomization @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/base/common.properties
 color=blue
@@ -171,14 +171,14 @@ EOF
 Make an abbreviation for the parent of the overlay
 directories:
 
-<!-- @overlays @test -->
+<!-- @overlays @testAgainstLatestRelease -->
 ```
 OVERLAYS=$DEMO_HOME/overlays
 ```
 
 Create the files that define the _development_ overlay:
 
-<!-- @developmentFiles @test -->
+<!-- @developmentFiles @testAgainstLatestRelease -->
 ```
 mkdir -p $OVERLAYS/development
 
@@ -206,7 +206,7 @@ EOF
 
 One can now generate the configMaps for development:
 
-<!-- @runDev @test -->
+<!-- @runDev @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/development
 ```
@@ -260,7 +260,7 @@ deletes unused configMaps.
 Next, create the files for the _production_ overlay:
 
 
-<!-- @productionFiles @test -->
+<!-- @productionFiles @testAgainstLatestRelease -->
 ```
 mkdir -p $OVERLAYS/production
 
@@ -287,7 +287,7 @@ EOF
 
 One can now generate the configMaps for production:
 
-<!-- @runProd @test -->
+<!-- @runProd @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/production
 ```
diff --git a/examples/configGeneration.md b/examples/configGeneration.md
index 92561ffae3..25d286c702 100644
--- a/examples/configGeneration.md
+++ b/examples/configGeneration.md
@@ -26,7 +26,7 @@ In this demo, the same [hello_world](helloWorld/README.md) is used while the Con
 ### Establish base and staging
 
 Establish the base with a configMapGenerator
-<!-- @establishBase @test -->
+<!-- @establishBase @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 
@@ -53,7 +53,7 @@ EOF
 ```
 
 Establish the staging with a patch applied to the ConfigMap
-<!-- @establishStaging @test -->
+<!-- @establishStaging @testAgainstLatestRelease -->
 ```
 OVERLAYS=$DEMO_HOME/overlays
 mkdir -p $OVERLAYS/staging
@@ -91,7 +91,7 @@ configured with data from a configMap.
 The deployment refers to this map by name:
 
 
-<!-- @showDeployment @test -->
+<!-- @showDeployment @testAgainstLatestRelease -->
 ```
 grep -C 2 configMapKeyRef $BASE/deployment.yaml
 ```
@@ -117,7 +117,7 @@ collected](https://github.com/kubernetes-sigs/kustomize/issues/242).
 
 The _staging_ [variant] here has a configMap [patch]:
 
-<!-- @showMapPatch @test -->
+<!-- @showMapPatch @testAgainstLatestRelease -->
 ```
 cat $OVERLAYS/staging/map.yaml
 ```
@@ -128,7 +128,7 @@ resource spec.
 
 The ConfigMap it modifies is declared from a configMapGenerator.
 
-<!-- @showMapBase @test -->
+<!-- @showMapBase @testAgainstLatestRelease -->
 ```
 grep -C 4 configMapGenerator $BASE/kustomization.yaml
 ```
@@ -141,7 +141,7 @@ _not_ what gets used in the cluster.  By design,
 kustomize modifies names of ConfigMaps declared from ConfigMapGenerator.  To see the names
 ultimately used in the cluster, just run kustomize:
 
-<!-- @grepStagingName @test -->
+<!-- @grepStagingName @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging |\
     grep -B 8 -A 1 staging-the-map
@@ -159,7 +159,7 @@ The suffix to the configMap name is generated from a
 hash of the maps content - in this case the name suffix
 is _k25m8k5k5m_:
 
-<!-- @grepStagingHash @test -->
+<!-- @grepStagingHash @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging | grep k25m8k5k5m
 ```
@@ -167,7 +167,7 @@ kustomize build $OVERLAYS/staging | grep k25m8k5k5m
 Now modify the map patch, to change the greeting
 the server will use:
 
-<!-- @changeMap @test -->
+<!-- @changeMap @testAgainstLatestRelease -->
 ```
 sed -i.bak 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml
 ```
@@ -181,7 +181,7 @@ kustomize build $OVERLAYS/staging |\
 
 Run kustomize again to see the new configMap names:
 
-<!-- @grepStagingName @test -->
+<!-- @grepStagingName @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging |\
     grep -B 8 -A 1 staging-the-map
@@ -192,7 +192,7 @@ in three new names ending in _cd7kdh48fd_ - one in the
 configMap name itself, and two in the deployment that
 uses the map:
 
-<!-- @countHashes @test -->
+<!-- @countHashes @testAgainstLatestRelease -->
 ```
 test 3 == \
   $(kustomize build $OVERLAYS/staging | grep cd7kdh48fd | wc -l); \
diff --git a/examples/generatorOptions.md b/examples/generatorOptions.md
index fcda27a841..3045eaebf1 100644
--- a/examples/generatorOptions.md
+++ b/examples/generatorOptions.md
@@ -13,7 +13,7 @@ DEMO_HOME=$(mktemp -d)
 
 Create a kustomization and add a ConfigMap generator to it.
 
-<!-- @createCMGenerator @test -->
+<!-- @createCMGenerator @testAgainstLatestRelease -->
 ```
 cat > $DEMO_HOME/kustomization.yaml << EOF
 configMapGenerator:
@@ -25,7 +25,7 @@ EOF
 ```
 
 Add following generatorOptions
-<!-- @addGeneratorOptions @test -->
+<!-- @addGeneratorOptions @testAgainstLatestRelease -->
 ```
 cat >> $DEMO_HOME/kustomization.yaml << EOF
 generatorOptions:
@@ -39,7 +39,7 @@ EOF
 Run `kustomize build` and make sure that the generated ConfigMap
  
  - doesn't have name suffix
-    <!-- @verify @test -->
+    <!-- @verify @testAgainstLatestRelease -->
     ```
     test 1 == \
     $(kustomize build $DEMO_HOME | grep "name: my-configmap$" | wc -l); \
diff --git a/examples/helloWorld/README.md b/examples/helloWorld/README.md
index 591f0fdf60..59ce9796b9 100644
--- a/examples/helloWorld/README.md
+++ b/examples/helloWorld/README.md
@@ -22,7 +22,7 @@ Steps:
 
 First define a place to work:
 
-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -44,7 +44,7 @@ To keep this document shorter, the base resources are
 off in a supplemental data directory rather than
 declared here as HERE documents.  Download them:
 
-<!-- @downloadBase @test -->
+<!-- @downloadBase @testAgainstLatestRelease -->
 ```
 BASE=$DEMO_HOME/base
 mkdir -p $BASE
@@ -57,7 +57,7 @@ curl -s -o "$BASE/#1.yaml" "https://raw.githubusercontent.com\
 
 Look at the directory:
 
-<!-- @runTree @test -->
+<!-- @runTree @testAgainstLatestRelease -->
 ```
 tree $DEMO_HOME
 ```
@@ -88,7 +88,7 @@ would only recognize the resource files.
 
 The `base` directory has a [kustomization] file:
 
-<!-- @showKustomization @test -->
+<!-- @showKustomization @testAgainstLatestRelease -->
 ```
 more $BASE/kustomization.yaml
 ```
@@ -96,7 +96,7 @@ more $BASE/kustomization.yaml
 Optionally, run `kustomize` on the base to emit
 customized resources to `stdout`:
 
-<!-- @buildBase @test -->
+<!-- @buildBase @testAgainstLatestRelease -->
 ```
 kustomize build $BASE
 ```
@@ -106,14 +106,14 @@ kustomize build $BASE
 A first customization step could be to change the _app
 label_ applied to all resources:
 
-<!-- @addLabel @test -->
+<!-- @addLabel @testAgainstLatestRelease -->
 ```
 sed -i.bak 's/app: hello/app: my-hello/' \
     $BASE/kustomization.yaml
 ```
 
 See the effect:
-<!-- @checkLabel @test -->
+<!-- @checkLabel @testAgainstLatestRelease -->
 ```
 kustomize build $BASE | grep -C 3 app:
 ```
@@ -127,7 +127,7 @@ Create a _staging_ and _production_ [overlay]:
  * Web server greetings from these cluster
    [variants] will differ from each other.
 
-<!-- @overlayDirectories @test -->
+<!-- @overlayDirectories @testAgainstLatestRelease -->
 ```
 OVERLAYS=$DEMO_HOME/overlays
 mkdir -p $OVERLAYS/staging
@@ -139,7 +139,7 @@ mkdir -p $OVERLAYS/production
 In the `staging` directory, make a kustomization
 defining a new name prefix, and some different labels.
 
-<!-- @makeStagingKustomization @test -->
+<!-- @makeStagingKustomization @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$OVERLAYS/staging/kustomization.yaml
 namePrefix: staging-
@@ -162,7 +162,7 @@ greeting from _Good Morning!_ to _Have a pineapple!_
 
 Also, enable the _risky_ flag.
 
-<!-- @stagingMap @test -->
+<!-- @stagingMap @testAgainstLatestRelease -->
 ```
 cat <<EOF >$OVERLAYS/staging/map.yaml
 apiVersion: v1
@@ -180,7 +180,7 @@ EOF
 In the production directory, make a kustomization
 with a different name prefix and labels.
 
-<!-- @makeProductionKustomization @test -->
+<!-- @makeProductionKustomization @testAgainstLatestRelease -->
 ```
 cat <<EOF >$OVERLAYS/production/kustomization.yaml
 namePrefix: production-
@@ -202,7 +202,7 @@ EOF
 Make a production patch that increases the replica
 count (because production takes more traffic).
 
-<!-- @productionDeployment @test -->
+<!-- @productionDeployment @testAgainstLatestRelease -->
 ```
 cat <<EOF >$OVERLAYS/production/deployment.yaml
 apiVersion: apps/v1
@@ -228,7 +228,7 @@ EOF
 
 Review the directory structure and differences:
 
-<!-- @listFiles @test -->
+<!-- @listFiles @testAgainstLatestRelease -->
 ```
 tree $DEMO_HOME
 ```
@@ -288,12 +288,12 @@ something like
 
 The individual resource sets are:
 
-<!-- @buildStaging @test -->
+<!-- @buildStaging @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging
 ```
 
-<!-- @buildProduction @test -->
+<!-- @buildProduction @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/production
 ```
diff --git a/examples/image.md b/examples/image.md
index 6e3eed6c09..3c35992626 100644
--- a/examples/image.md
+++ b/examples/image.md
@@ -3,14 +3,14 @@
 
 Define a place to work:
 
-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
 
 Make a `kustomization` containing a pod resource
 
-<!-- @createKustomization @test -->
+<!-- @createKustomization @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/kustomization.yaml
 resources:
@@ -20,7 +20,7 @@ EOF
 
 Declare the pod resource
 
-<!-- @createDeployment @test -->
+<!-- @createDeployment @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/pod.yaml
 apiVersion: v1
@@ -46,7 +46,7 @@ The image `busybox` and tag `1.29.0` can be changed by adding `images` in `kusto
 
 
 Add `images`:
-<!-- @addImages @test -->
+<!-- @addImages @testAgainstLatestRelease -->
 ```
 cd $DEMO_HOME
 kustomize edit set image busybox=alpine:3.6
@@ -61,14 +61,14 @@ The following `images` will be added to `kustomization.yaml`:
 > ```
 
 Now build this `kustomization`
-<!-- @kustomizeBuild @test -->
+<!-- @kustomizeBuild @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME
 ```
 
 Confirm that this replaces _both_ busybox images and tags for `alpine:3.6`:
 
-<!-- @confirmImages @test -->
+<!-- @confirmImages @testAgainstLatestRelease -->
 ```
 test 2 = \
   $(kustomize build $DEMO_HOME | grep alpine:3.6 | wc -l); \
diff --git a/examples/jsonpatch.md b/examples/jsonpatch.md
index 61c00f38f5..b2f334c91b 100644
--- a/examples/jsonpatch.md
+++ b/examples/jsonpatch.md
@@ -6,7 +6,7 @@ The example below modifies an `Ingress` object with such a patch.
 
 Make a `kustomization` containing an ingress resource.
 
-<!-- @createIngress @test -->
+<!-- @createIngress @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 
@@ -36,7 +36,7 @@ Declare a JSON patch file to update two fields of the Ingress object:
 - change host from `foo.bar.com` to `foo.bar.io`
 - change servicePort from `80` to `8080`
 
-<!-- @addJsonPatch @test -->
+<!-- @addJsonPatch @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/ingress_patch.json
 [
@@ -48,7 +48,7 @@ EOF
 
 You can also write the patch in YAML format. This example also shows the "add" operation:
 
-<!-- @addYamlPatch @test -->
+<!-- @addYamlPatch @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/ingress_patch.yaml
 - op: replace
@@ -67,7 +67,7 @@ EOF
 
 Apply the patch by adding _patchesJson6902_ field in kustomization.yaml
 
-<!-- @applyJsonPatch @test -->
+<!-- @applyJsonPatch @testAgainstLatestRelease -->
 ```
 cat <<EOF >>$DEMO_HOME/kustomization.yaml
 patchesJson6902:
@@ -81,14 +81,14 @@ EOF
 ```
 
 Running `kustomize build $DEMO_HOME`, in the output confirm that host has been updated correctly.
-<!-- @confirmHost @test -->
+<!-- @confirmHost @testAgainstLatestRelease -->
 ```
 test 1 == \
   $(kustomize build $DEMO_HOME | grep "host: foo.bar.io" | wc -l); \
   echo $?
 ```
 Running `kustomize build $DEMO_HOME`, in the output confirm that the servicePort has been updated correctly.
-<!-- @confirmServicePort @test -->
+<!-- @confirmServicePort @testAgainstLatestRelease -->
 ```
 test 1 == \
   $(kustomize build $DEMO_HOME | grep "servicePort: 8080" | wc -l); \
@@ -97,7 +97,7 @@ test 1 == \
 
 If the patch is YAML-formatted, it will be parsed correctly:
 
-<!-- @applyYamlPatch @test -->
+<!-- @applyYamlPatch @testAgainstLatestRelease -->
 ```
 cat <<EOF >>$DEMO_HOME/kustomization.yaml
 patchesJson6902:
@@ -110,7 +110,7 @@ patchesJson6902:
 EOF
 ```
 
-<!-- @confirmYamlPatch @test -->
+<!-- @confirmYamlPatch @testAgainstLatestRelease -->
 ```
 test 1 == \
   $(kustomize build $DEMO_HOME | grep "path: /test" | wc -l); \
diff --git a/examples/ldap/README.md b/examples/ldap/README.md
index 8d7a4c39dd..af28ce2f28 100644
--- a/examples/ldap/README.md
+++ b/examples/ldap/README.md
@@ -18,7 +18,7 @@ Steps:
 
 First define a place to work:
 
-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -38,7 +38,7 @@ To keep this document shorter, the base resources are
 off in a supplemental data directory rather than
 declared here as HERE documents.  Download them:
 
-<!-- @downloadBase @test -->
+<!-- @downloadBase @testAgainstLatestRelease -->
 ```
 BASE=$DEMO_HOME/base
 mkdir -p $BASE
@@ -53,7 +53,7 @@ curl -s -o "$BASE/#1" "$CONTENT/base\
 
 Look at the directory:
 
-<!-- @runTree @test -->
+<!-- @runTree @testAgainstLatestRelease -->
 ```
 tree $DEMO_HOME
 ```
@@ -84,7 +84,7 @@ would only recognize the resource files.
 
 The `base` directory has a [kustomization] file:
 
-<!-- @showKustomization @test -->
+<!-- @showKustomization @testAgainstLatestRelease -->
 ```
 more $BASE/kustomization.yaml
 ```
@@ -92,7 +92,7 @@ more $BASE/kustomization.yaml
 Optionally, run `kustomize` on the base to emit
 customized resources to `stdout`:
 
-<!-- @buildBase @test -->
+<!-- @buildBase @testAgainstLatestRelease -->
 ```
 kustomize build $BASE
 ```
@@ -101,14 +101,14 @@ kustomize build $BASE
 
 A first customization step could be to set the name prefix to all resources:
 
-<!-- @namePrefix @test -->
+<!-- @namePrefix @testAgainstLatestRelease -->
 ```
 cd $BASE
 kustomize edit set nameprefix "my-"
 ```
 
 See the effect:
-<!-- @checkNameprefix @test -->
+<!-- @checkNameprefix @testAgainstLatestRelease -->
 ```
 kustomize build $BASE | grep -C 3 "my-"
 ```
@@ -121,7 +121,7 @@ Create a _staging_ and _production_ [overlay]:
  * _Production_ has a higher replica count and a persistent disk.
  * [variants] will differ from each other.
 
-<!-- @overlayDirectories @test -->
+<!-- @overlayDirectories @testAgainstLatestRelease -->
 ```
 OVERLAYS=$DEMO_HOME/overlays
 mkdir -p $OVERLAYS/staging
@@ -132,7 +132,7 @@ mkdir -p $OVERLAYS/production
 
 Download the staging customization and patch.
 
-<!-- @downloadStagingKustomization @test -->
+<!-- @downloadStagingKustomization @testAgainstLatestRelease -->
 ```
 curl -s -o "$OVERLAYS/staging/#1" "$CONTENT/overlays/staging\
 /{config.env,deployment.yaml,kustomization.yaml}"
@@ -159,7 +159,7 @@ as well as 2 replica
 #### Production Kustomization
 
 Download the production customization and patch.
-<!-- @downloadProductionKustomization @test -->
+<!-- @downloadProductionKustomization @testAgainstLatestRelease -->
 ```
 curl -s -o "$OVERLAYS/production/#1" "$CONTENT/overlays/production\
 /{deployment.yaml,kustomization.yaml}"
@@ -196,7 +196,7 @@ The production customization adds 6 replica as well as a consistent disk.
 
 Review the directory structure and differences:
 
-<!-- @listFiles @test -->
+<!-- @listFiles @testAgainstLatestRelease -->
 ```
 tree $DEMO_HOME
 ```
@@ -258,12 +258,12 @@ The difference output should look something like
 
 The individual resource sets are:
 
-<!-- @buildStaging @test -->
+<!-- @buildStaging @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging
 ```
 
-<!-- @buildProduction @test -->
+<!-- @buildProduction @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/production
 ```
diff --git a/examples/multibases/README.md b/examples/multibases/README.md
index 4d2b11de18..d77bbb7ec5 100644
--- a/examples/multibases/README.md
+++ b/examples/multibases/README.md
@@ -20,13 +20,13 @@ that is just a single pod.
 
 Define a place to work:
 
-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
 
 Define a common base:
-<!-- @makeBase @test -->
+<!-- @makeBase @testAgainstLatestRelease -->
 ```
 BASE=$DEMO_HOME/base
 mkdir $BASE
@@ -51,7 +51,7 @@ EOF
 ```
 
 Define a dev variant overlaying base:
-<!-- @makeDev @test -->
+<!-- @makeDev @testAgainstLatestRelease -->
 ```
 DEV=$DEMO_HOME/dev
 mkdir $DEV
@@ -64,7 +64,7 @@ EOF
 ```
 
 Define a staging variant overlaying base:
-<!-- @makeStaging @test -->
+<!-- @makeStaging @testAgainstLatestRelease -->
 ```
 STAG=$DEMO_HOME/staging
 mkdir $STAG
@@ -77,7 +77,7 @@ EOF
 ```
 
 Define a production variant overlaying base:
-<!-- @makeProd @test -->
+<!-- @makeProd @testAgainstLatestRelease -->
 ```
 PROD=$DEMO_HOME/production
 mkdir $PROD
@@ -90,7 +90,7 @@ EOF
 ```
 
 Then define a _Kustomization_ composing three variants together:
-<!-- @makeTopLayer @test -->
+<!-- @makeTopLayer @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/kustomization.yaml
 resources:
@@ -119,7 +119,7 @@ Now the workspace has following directories
 
 Confirm that the `kustomize build` output contains three pod objects from dev, staging and production variants.
 
-<!-- @confirmVariants @test -->
+<!-- @confirmVariants @testAgainstLatestRelease -->
 ```
 test 1 == \
   $(kustomize build $DEMO_HOME | grep cluster-a-dev-myapp-pod | wc -l); \
diff --git a/examples/multibases/multi-namespace.md b/examples/multibases/multi-namespace.md
index a077505b25..c16edc52ac 100644
--- a/examples/multibases/multi-namespace.md
+++ b/examples/multibases/multi-namespace.md
@@ -8,13 +8,13 @@ following demonstrates this using a base that's just one pod.
 
 Define a place to work:
 
-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
 
 Define a common base:
-<!-- @makeBase @test -->
+<!-- @makeBase @testAgainstLatestRelease -->
 ```
 BASE=$DEMO_HOME/base
 mkdir $BASE
@@ -39,7 +39,7 @@ EOF
 ```
 
 Define a variant in namespace-a overlaying base:
-<!-- @makeNamespaceA @test -->
+<!-- @makeNamespaceA @testAgainstLatestRelease -->
 ```
 NSA=$DEMO_HOME/namespace-a
 mkdir $NSA
@@ -60,7 +60,7 @@ EOF
 ```
 
 Define a variant in namespace-b overlaying base:
-<!-- @makeNamespaceB @test -->
+<!-- @makeNamespaceB @testAgainstLatestRelease -->
 ```
 NSB=$DEMO_HOME/namespace-b
 mkdir $NSB
@@ -81,7 +81,7 @@ EOF
 ```
 
 Then define a _Kustomization_ composing two variants together:
-<!-- @makeTopLayer @test -->
+<!-- @makeTopLayer @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/kustomization.yaml
 resources:
@@ -107,7 +107,7 @@ Now the workspace has following directories
 
 Confirm that the `kustomize build` output contains two pod objects from namespace-a and namespace-b.
 
-<!-- @confirmVariants @test -->
+<!-- @confirmVariants @testAgainstLatestRelease -->
 ```
 test 2 == \
   $(kustomize build $DEMO_HOME| grep -B 4 "namespace: namespace-[ab]" | grep "name: myapp-pod" | wc -l); \
diff --git a/examples/mySql/README.md b/examples/mySql/README.md
index 021d57be84..780584054f 100644
--- a/examples/mySql/README.md
+++ b/examples/mySql/README.md
@@ -11,7 +11,7 @@ In the production environment we want:
 - MySQL to use persistent disk for storing data.
 
 First make a place to work:
-<!-- @makeDemoHome @test -->
+<!-- @makeDemoHome @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -25,7 +25,7 @@ as HERE documents.
 
 Download them:
 
-<!-- @downloadResources @test -->
+<!-- @downloadResources @testAgainstLatestRelease -->
 ```
 curl -s  -o "$DEMO_HOME/#1.yaml" "https://raw.githubusercontent.com\
 /kubernetes-sigs/kustomize\
@@ -40,14 +40,14 @@ a file called `kustomization.yaml`.
 
 Start this file:
 
-<!-- @kustomizeYaml @test -->
+<!-- @kustomizeYaml @testAgainstLatestRelease -->
 ```
 touch $DEMO_HOME/kustomization.yaml
 ```
 
 ### Add the resources
 
-<!-- @addResources @test -->
+<!-- @addResources @testAgainstLatestRelease -->
 ```
 cd $DEMO_HOME
 
@@ -73,7 +73,7 @@ Arrange for the MySQL resources to begin with prefix
 _prod-_ (since they are meant for the _production_
 environment):
 
-<!-- @customizeLabel @test -->
+<!-- @customizeLabel @testAgainstLatestRelease -->
 ```
 cd $DEMO_HOME
 
@@ -91,7 +91,7 @@ cat kustomization.yaml
 This `namePrefix` directive adds _prod-_ to all
 resource names.
 
-<!-- @genNamePrefixConfig @test -->
+<!-- @genNamePrefixConfig @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME
 ```
@@ -134,7 +134,7 @@ selector.
 `kustomize` does not have `edit set label` command to add
 a label, but one can always edit `kustomization.yaml` directly:
 
-<!-- @customizeLabels @test -->
+<!-- @customizeLabels @testAgainstLatestRelease -->
 ```
 sed -i.bak 's/app: helloworld/app: prod/' \
     $DEMO_HOME/kustomization.yaml
@@ -153,7 +153,7 @@ environment. So we want to use Persistent Disk in
 production. kustomize lets you apply `patchesStrategicMerge` to the
 resources.
 
-<!-- @createPatchFile @test -->
+<!-- @createPatchFile @testAgainstLatestRelease -->
 ```
 cat <<'EOF' > $DEMO_HOME/persistent-disk.yaml
 apiVersion: apps/v1beta2 # for versions before 1.9.0 use apps/v1beta2
@@ -173,7 +173,7 @@ EOF
 
 Add the patch file to `kustomization.yaml`:
 
-<!-- @specifyPatch @test -->
+<!-- @specifyPatch @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >> $DEMO_HOME/kustomization.yaml
 patchesStrategicMerge:
@@ -199,7 +199,7 @@ The output of the following command can now be applied
 to the cluster (i.e. piped to `kubectl apply`) to
 create the production environment.
 
-<!-- @finalInflation @test -->
+<!-- @finalInflation @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME  # | kubectl apply -f -
 ```
diff --git a/examples/patchMultipleObjects.md b/examples/patchMultipleObjects.md
index c9b87f3169..cf7421efe8 100644
--- a/examples/patchMultipleObjects.md
+++ b/examples/patchMultipleObjects.md
@@ -29,7 +29,7 @@ The example below shows how to inject a sidecar container for all deployment res
 
 Make a `kustomization` containing a Deployment resource.
 
-<!-- @createDeployment @test -->
+<!-- @createDeployment @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 
@@ -74,7 +74,7 @@ EOF
 
 Declare a Strategic Merge Patch file to inject a sidecar container:
 
-<!-- @addPatch @test -->
+<!-- @addPatch @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/patch.yaml
 apiVersion: apps/v1
@@ -95,7 +95,7 @@ EOF
 
 Apply the patch by adding _patches_ field in kustomization.yaml
 
-<!-- @applyPatch @test -->
+<!-- @applyPatch @testAgainstLatestRelease -->
 ```
 cat <<EOF >>$DEMO_HOME/kustomization.yaml
 patches:
@@ -107,7 +107,7 @@ EOF
 
 Running `kustomize build $DEMO_HOME`, in the output confirm that both Deployment resources are patched correctly.
 
-<!-- @confirmPatch @test -->
+<!-- @confirmPatch @testAgainstLatestRelease -->
 ```
 test 2 == \
   $(kustomize build $DEMO_HOME | grep "image: docker.io/istio/proxyv2" | wc -l); \
diff --git a/examples/remoteBuild.md b/examples/remoteBuild.md
index 63038e5432..46d791f3a8 100644
--- a/examples/remoteBuild.md
+++ b/examples/remoteBuild.md
@@ -11,7 +11,7 @@ To try this immediately, run a build against the kustomization
 in the [multibases](multibases/README.md) example.  There's
 one pod in the output:
 
-<!-- @remoteOverlayBuild @test -->
+<!-- @remoteOverlayBuild @testAgainstLatestRelease -->
 
 ```
 target="github.com/kubernetes-sigs/kustomize//examples/multibases/dev/?ref=v1.0.6"
@@ -24,7 +24,7 @@ Run against the overlay in that example to get three pods
 (the overlay combines the dev, staging and prod bases for
 someone who wants to send them all at the same time):
 
-<!-- @remoteBuild @test -->
+<!-- @remoteBuild @testAgainstLatestRelease -->
 ```
 target="https://github.com/kubernetes-sigs/kustomize//examples/multibases?ref=v1.0.6"
 test 3 == \
@@ -34,7 +34,7 @@ test 3 == \
 
 A base can be a URL:
 
-<!-- @createOverlay @test -->
+<!-- @createOverlay @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 
@@ -48,7 +48,7 @@ EOF
 Build this to confirm that all three pods from the base
 have the `remote-` prefix.
 
-<!-- @remoteBases @test -->
+<!-- @remoteBases @testAgainstLatestRelease -->
 ```
 test 3 == \
   $(kustomize build $DEMO_HOME | grep remote-.*-myapp-pod | wc -l); \
diff --git a/examples/secretGeneratorPlugin.md b/examples/secretGeneratorPlugin.md
index 78e05a57f2..0c14b091df 100644
--- a/examples/secretGeneratorPlugin.md
+++ b/examples/secretGeneratorPlugin.md
@@ -25,7 +25,7 @@ etc.
 
 ## Make a place to work
 
-<!-- @establishBase @test -->
+<!-- @establishBase @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -43,7 +43,7 @@ Here's an example combining all three methods:
 
 Make an env file with some short secrets:
 
-<!-- @makeEnvFile @test -->
+<!-- @makeEnvFile @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$DEMO_HOME/foo.env
 ROUTER_PASSWORD=admin
@@ -53,7 +53,7 @@ EOF
 
 Make a text file with a long secret:
 
-<!-- @makeLongSecretFile @test -->
+<!-- @makeLongSecretFile @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$DEMO_HOME/longsecret.txt
 Lorem ipsum dolor sit amet,
@@ -67,7 +67,7 @@ And make a kustomization file referring to the
 above and _additionally_ defining some literal KV
 pairs in line:
 
-<!-- @makeKustomization1 @test -->
+<!-- @makeKustomization1 @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$DEMO_HOME/kustomization.yaml
 secretGenerator:
@@ -84,7 +84,7 @@ EOF
 
 Now generate the Secret:
 
-<!-- @build1 @test -->
+<!-- @build1 @testAgainstLatestRelease -->
 ```
 result=$(kustomize build $DEMO_HOME)
 echo "$result"
@@ -141,7 +141,7 @@ from a database.
 
 Download it
 
-<!-- @copyPlugin @test -->
+<!-- @copyPlugin @testAgainstLatestRelease -->
 ```
 repo=https://raw.githubusercontent.com/kubernetes-sigs/kustomize
 pPath=plugin/someteam.example.com/v1/secretsfromdatabase
@@ -165,7 +165,7 @@ go build -buildmode plugin \
 
 Create a configuration file for it:
 
-<!-- @makeConfiguration @test -->
+<!-- @makeConfiguration @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$DEMO_HOME/secretFromDb.yaml
 apiVersion: someteam.example.com/v1
@@ -183,7 +183,7 @@ EOF
 Create a new kustomization file
 referencing this plugin:
 
-<!-- @makeKustomization2 @test -->
+<!-- @makeKustomization2 @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$DEMO_HOME/kustomization.yaml
 generators:
diff --git a/examples/springboot/README.md b/examples/springboot/README.md
index a3f7e222be..11d831662d 100644
--- a/examples/springboot/README.md
+++ b/examples/springboot/README.md
@@ -13,7 +13,7 @@ In the production environment we want to customize the following:
 - health check and readiness check.
 
 First make a place to work:
-<!-- @makeDemoHome @test -->
+<!-- @makeDemoHome @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -27,7 +27,7 @@ as HERE documents.
 
 Download them:
 
-<!-- @downloadResources @test -->
+<!-- @downloadResources @testAgainstLatestRelease -->
 ```
 CONTENT="https://raw.githubusercontent.com\
 /kubernetes-sigs/kustomize\
@@ -44,14 +44,14 @@ a file called `kustomization.yaml`.
 
 Start this file:
 
-<!-- @kustomizeYaml @test -->
+<!-- @kustomizeYaml @testAgainstLatestRelease -->
 ```
 touch $DEMO_HOME/kustomization.yaml
 ```
 
 ### Add the resources
 
-<!-- @addResources @test -->
+<!-- @addResources @testAgainstLatestRelease -->
 ```
 cd $DEMO_HOME
 
@@ -71,7 +71,7 @@ cat kustomization.yaml
 
 ### Add configMap generator
 
-<!-- @addConfigMap @test -->
+<!-- @addConfigMap @testAgainstLatestRelease -->
 ```
 echo "app.name=Kustomize Demo" >$DEMO_HOME/application.properties
 
@@ -102,7 +102,7 @@ For Spring Boot application, we can set an active profile through the environmen
 the application will pick up an extra `application-<profile>.properties` file. With this, we can customize the configMap in two
 steps. Add an environment variable through the patch and add a file to the configMap.
 
-<!-- @customizeConfigMap @test -->
+<!-- @customizeConfigMap @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/patch.yaml
 apiVersion: apps/v1beta2
@@ -149,7 +149,7 @@ Arrange for the resources to begin with prefix
 _prod-_ (since they are meant for the _production_
 environment):
 
-<!-- @customizeLabel @test -->
+<!-- @customizeLabel @testAgainstLatestRelease -->
 ```
 cd $DEMO_HOME
 kustomize edit set nameprefix 'prod-'
@@ -165,7 +165,7 @@ This `namePrefix` directive adds _prod-_ to all
 resource names, as can be seen by building the
 resources:
 
-<!-- @build1 @test -->
+<!-- @build1 @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME | grep prod-
 ```
@@ -180,7 +180,7 @@ selector.
 add a label, but one can always edit
 `kustomization.yaml` directly:
 
-<!-- @customizeLabels @test -->
+<!-- @customizeLabels @testAgainstLatestRelease -->
 ```
 cat <<EOF >>$DEMO_HOME/kustomization.yaml
 commonLabels:
@@ -191,7 +191,7 @@ EOF
 Confirm that the resources now all have names prefixed
 by `prod-` and the label tuple `env:prod`:
 
-<!-- @build2 @test -->
+<!-- @build2 @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME | grep -C 3 env
 ```
@@ -205,7 +205,7 @@ set JVM options accordingly.
 
 Download the patch `memorylimit_patch.yaml`. It contains the memory limits setup.
 
-<!-- @downloadPatch @test -->
+<!-- @downloadPatch @testAgainstLatestRelease -->
 ```
 curl -s  -o "$DEMO_HOME/#1.yaml" \
   "$CONTENT/overlays/production/{memorylimit_patch}.yaml"
@@ -243,7 +243,7 @@ has end points such as `/actuator/health` for this. We can customize the k8s dep
 
 Download the patch `healthcheck_patch.yaml`. It contains the liveness probes and readyness probes.
 
-<!-- @downloadPatch @test -->
+<!-- @downloadPatch @testAgainstLatestRelease -->
 ```
 curl -s  -o "$DEMO_HOME/#1.yaml" \
   "$CONTENT/overlays/production/{healthcheck_patch}.yaml"
@@ -281,7 +281,7 @@ The output contains
 
 Add these patches to the kustomization:
 
-<!-- @addPatch @test -->
+<!-- @addPatch @testAgainstLatestRelease -->
 ```
 cd $DEMO_HOME
 kustomize edit add patch memorylimit_patch.yaml
@@ -301,7 +301,7 @@ The output of the following command can now be applied
 to the cluster (i.e. piped to `kubectl apply`) to
 create the production environment.
 
-<!-- @finalBuild @test -->
+<!-- @finalBuild @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME  # | kubectl apply -f -
 ```
diff --git a/examples/transformerconfigs/crd/README.md b/examples/transformerconfigs/crd/README.md
index 00aee7f803..5bf85eb2b4 100644
--- a/examples/transformerconfigs/crd/README.md
+++ b/examples/transformerconfigs/crd/README.md
@@ -3,7 +3,7 @@
 This tutorial shows how to add transformer configurations to support a custom resource.
 
 Create a workspace by
-<!-- @createws @test -->
+<!-- @createws @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -17,7 +17,7 @@ Consider a CRD of kind `MyKind` with fields
 - `.spec.selectors` as the label selectors
 
 Add the following file to configure the transformers for the above fields
-<!-- @addConfig @test -->
+<!-- @addConfig @testAgainstLatestRelease -->
 ```
 mkdir $DEMO_HOME/kustomizeconfig
 cat > $DEMO_HOME/kustomizeconfig/mykind.yaml << EOF
@@ -51,7 +51,7 @@ EOF
 Create a file with some resources that
 includes an instance of `MyKind`:
 
-<!-- @createResource @test -->
+<!-- @createResource @testAgainstLatestRelease -->
 ```
 cat > $DEMO_HOME/resources.yaml << EOF
 apiVersion: v1
@@ -88,7 +88,7 @@ EOF
 
 Create a kustomization referring to it:
 
-<!-- @createKustomization @test -->
+<!-- @createKustomization @testAgainstLatestRelease -->
 ```
 cat > $DEMO_HOME/kustomization.yaml << EOF
 resources:
@@ -112,7 +112,7 @@ EOF
 
 Use the customized transformer configurations by specifying them
 in the kustomization file:
-<!-- @addTransformerConfigs @test -->
+<!-- @addTransformerConfigs @testAgainstLatestRelease -->
 ```
 cat >> $DEMO_HOME/kustomization.yaml << EOF
 configurations:
@@ -122,7 +122,7 @@ EOF
 
 Run `kustomize build` and verify that the namereference is correctly resolved.
 
-<!-- @build @test -->
+<!-- @build @testAgainstLatestRelease -->
 ```
 test 2 == \
 $(kustomize build $DEMO_HOME | grep -A 2 ".*Ref" | grep "test-" | wc -l); \
@@ -131,7 +131,7 @@ echo $?
 
 Run `kustomize build` and verify that the vars correctly resolved.
 
-<!-- @verify @test -->
+<!-- @verify @testAgainstLatestRelease -->
 ```
 test 0 == \
 $(kustomize build $DEMO_HOME | grep "BEE_ACTION" | wc -l); \
diff --git a/examples/transformerconfigs/images/README.md b/examples/transformerconfigs/images/README.md
index 22283b0094..e59dd3ea07 100644
--- a/examples/transformerconfigs/images/README.md
+++ b/examples/transformerconfigs/images/README.md
@@ -3,7 +3,7 @@
 This tutorial shows how to modify images in resources, and create a custom images transformer configuration.
 
 Create a workspace by
-<!-- @createws @test -->
+<!-- @createws @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -15,7 +15,7 @@ Consider a Custom Resource Definition(CRD) of kind `MyKind` with field
 
 Add the following file to configure the images transformer for the CRD:
 
-<!-- @addConfig @test -->
+<!-- @addConfig @testAgainstLatestRelease -->
 ```
 mkdir $DEMO_HOME/kustomizeconfig
 cat > $DEMO_HOME/kustomizeconfig/mykind.yaml << EOF
@@ -30,7 +30,7 @@ EOF
 
 Create a file with some resources that includes an instance of `MyKind`:
 
-<!-- @createResource @test -->
+<!-- @createResource @testAgainstLatestRelease -->
 ```
 cat > $DEMO_HOME/resources.yaml << EOF
 
@@ -66,7 +66,7 @@ EOF
 
 Create a kustomization.yaml referring to it:
 
-<!-- @createKustomization @test -->
+<!-- @createKustomization @testAgainstLatestRelease -->
 ```
 cat > $DEMO_HOME/kustomization.yaml << EOF
 resources:
@@ -90,7 +90,7 @@ EOF
 
 Use the customized transformer configurations by specifying them
 in the kustomization file:
-<!-- @addTransformerConfigs @test -->
+<!-- @addTransformerConfigs @testAgainstLatestRelease -->
 ```
 cat >> $DEMO_HOME/kustomization.yaml << EOF
 configurations:
@@ -100,27 +100,27 @@ EOF
 
 Run `kustomize build` and verify that the images have been updated.
 
-<!-- @build @test -->
+<!-- @build @testAgainstLatestRelease -->
 ```
 test 1 == \
 $(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "new-crd-image:new-v1-tag" | wc -l); \
 echo $?
 ```
 
-<!-- @build @test -->
+<!-- @build @testAgainstLatestRelease -->
 ```
 test 1 == \
 $(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "new-app-1:MYNEWTAG-1" | wc -l); \
 echo $?
 ```
 
-<!-- @build @test -->
+<!-- @build @testAgainstLatestRelease -->
 ```
 test 1 == \
 $(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "my-docker2@sha" | wc -l); \
 echo $?
 ```
-<!-- @build @test -->
+<!-- @build @testAgainstLatestRelease -->
 ```
 test 1 == \
 $(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "prod-mysql:v3" | wc -l); \
diff --git a/examples/validationTransformer/README.md b/examples/validationTransformer/README.md
index 463755a3a9..a35235021e 100644
--- a/examples/validationTransformer/README.md
+++ b/examples/validationTransformer/README.md
@@ -24,7 +24,7 @@ loaded by Kustomize.
 
 Make a place to work:
 
-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 mkdir -p $DEMO_HOME/valid
@@ -38,7 +38,7 @@ mkdir -p $PLUGINDIR
 Download the [kubeval] binary depending on the operating system
 and add it to $PATH.
 
-<!-- @downloadKubeval @test -->
+<!-- @downloadKubeval @testAgainstLatestRelease -->
 ```
 OS=`uname | sed -e 's/Linux/linux/' -e 's/Darwin/darwin/'`
 wget https://github.com/instrumenta/kubeval/releases/download/0.9.2/kubeval-${OS}-amd64.tar.gz
@@ -60,7 +60,7 @@ A transformer plugin for the validation can be written as a
 bash script, which execute the [kubeval] binary and return proper
 output and exit code.
 
-<!-- @writePlugin @test -->
+<!-- @writePlugin @testAgainstLatestRelease -->
 ```
 cat <<'EOF' > $PLUGINDIR/Validator
 #!/bin/bash
@@ -95,7 +95,7 @@ chmod +x $PLUGINDIR/Validator
 Define a kustomization containing a valid ConfigMap
 and the transformer plugin.
 
-<!-- @writeKustomization @test -->
+<!-- @writeKustomization @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$DEMO_HOME/valid/configmap.yaml
 apiVersion: v1
@@ -125,7 +125,7 @@ EOF
 Define a kustomization containing an invalid ConfigMap
 and the transformer plugin.
 
-<!-- @writeKustomization @test -->
+<!-- @writeKustomization @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$DEMO_HOME/invalid/configmap.yaml
 apiVersion: v1
@@ -175,7 +175,7 @@ The directory structure is as the following:
 Define a helper function to run kustomize with the
 correct environment and flags for plugins:
 
-<!-- @defineKustomizeBd @test -->
+<!-- @defineKustomizeBd @testAgainstLatestRelease -->
 ```
 function kustomizeBd {
   XDG_CONFIG_HOME=$DEMO_HOME \
@@ -187,7 +187,7 @@ function kustomizeBd {
 
 Build the valid variant
 
-<!-- @buildValid @test -->
+<!-- @buildValid @testAgainstLatestRelease -->
 ```
 kustomizeBd valid
 ```
@@ -215,7 +215,7 @@ data: Invalid type. Expected: object, given: array
 
 ## cleanup
 
-<!-- @cleanup @test -->
+<!-- @cleanup @testAgainstLatestRelease -->
 ```shell
 rm -rf $DEMO_HOME
 ```
diff --git a/examples/wordpress/README.md b/examples/wordpress/README.md
index 13f91d2329..72fffb5cd4 100644
--- a/examples/wordpress/README.md
+++ b/examples/wordpress/README.md
@@ -8,7 +8,7 @@ To run WordPress, it's necessary to
 - access the service name of MySQL database from WordPress container
 
 First make a place to work:
-<!-- @makeDemoHome @test -->
+<!-- @makeDemoHome @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 MYSQL_HOME=$DEMO_HOME/mysql
@@ -21,7 +21,7 @@ mkdir -p $WORDPRESS_HOME
 
 Download the resources and `kustomization.yaml` for WordPress.
 
-<!-- @downloadResources @test -->
+<!-- @downloadResources @testAgainstLatestRelease -->
 ```
 CONTENT="https://raw.githubusercontent.com\
 /kubernetes-sigs/kustomize\
@@ -33,7 +33,7 @@ curl -s -o "$WORDPRESS_HOME/#1.yaml" \
 
 Download the resources and `kustomization.yaml` for MySQL.
 
-<!-- @downloadResources @test -->
+<!-- @downloadResources @testAgainstLatestRelease -->
 ```
 CONTENT="https://raw.githubusercontent.com\
 /kubernetes-sigs/kustomize\
@@ -48,7 +48,7 @@ curl -s -o "$MYSQL_HOME/#1.yaml" \
 Create a new kustomization with two bases,
 `wordpress` and `mysql`:
 
-<!-- @createKustomization @test -->
+<!-- @createKustomization @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/kustomization.yaml
 resources:
@@ -65,7 +65,7 @@ In the new kustomization, apply a patch for wordpress deployment. The patch does
 - Add an initial container to show the mysql service name
 - Add environment variable that allow wordpress to find the mysql database
 
-<!-- @downloadPatch @test -->
+<!-- @downloadPatch @testAgainstLatestRelease -->
 ```
 CONTENT="https://raw.githubusercontent.com\
 /kubernetes-sigs/kustomize\
@@ -105,7 +105,7 @@ $(WORDPRESS_SERVICE) and $(MYSQL_SERVICE).
 
 ### Bind the Variables to k8s Object Fields
 
-<!-- @addVarRef @test -->
+<!-- @addVarRef @testAgainstLatestRelease -->
 ```
 cat <<EOF >>$DEMO_HOME/kustomization.yaml
 vars:
@@ -128,7 +128,7 @@ EOF
 ### Substitution
 Confirm the variable substitution:
 
-<!-- @kustomizeBuild @test -->
+<!-- @kustomizeBuild @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME
 ```
diff --git a/examples/zh/configGeneration.md b/examples/zh/configGeneration.md
index 832fd1f3c5..aab17cfe25 100644
--- a/examples/zh/configGeneration.md
+++ b/examples/zh/configGeneration.md
@@ -30,7 +30,7 @@ kustomize 提供了两种添加 ConfigMap 的方法：
 ### 建立 base 和 staging
 
 使用 configMapGenerator 建立 base
-<!-- @establishBase @test -->
+<!-- @establishBase @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 
@@ -57,7 +57,7 @@ EOF
 ```
 
 通过应用 ConfigMap patch 的方式建立 staging
-<!-- @establishStaging @test -->
+<!-- @establishStaging @testAgainstLatestRelease -->
 ```
 OVERLAYS=$DEMO_HOME/overlays
 mkdir -p $OVERLAYS/staging
@@ -93,7 +93,7 @@ EOF
 
 deployment 按照名称引用此 ConfigMap ：
 
-<!-- @showDeployment @test -->
+<!-- @showDeployment @testAgainstLatestRelease -->
 ```
 grep -C 2 configMapKeyRef $BASE/deployment.yaml
 ```
@@ -111,7 +111,7 @@ grep -C 2 configMapKeyRef $BASE/deployment.yaml
 
 _staging_ 的 [variant] 包含一个 configMap 的 [patch]：
 
-<!-- @showMapPatch @test -->
+<!-- @showMapPatch @testAgainstLatestRelease -->
 ```
 cat $OVERLAYS/staging/map.yaml
 ```
@@ -120,7 +120,7 @@ cat $OVERLAYS/staging/map.yaml
 
 在 ConfigMapGenerator 中声明 ConfigMap 的修改。
 
-<!-- @showMapBase @test -->
+<!-- @showMapBase @testAgainstLatestRelease -->
 ```
 grep -C 4 configMapGenerator $BASE/kustomization.yaml
 ```
@@ -129,7 +129,7 @@ grep -C 4 configMapGenerator $BASE/kustomization.yaml
 
 但是，文件中指定的名称值不是群集中使用的名称值。根据设计，kustomize 修改从 ConfigMapGenerator 声明的 ConfigMaps 的名称。要查看最终在群集中使用的名称，只需运行 kustomize：
 
-<!-- @grepStagingName @test -->
+<!-- @grepStagingName @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging |\
     grep -B 8 -A 1 staging-the-map
@@ -141,14 +141,14 @@ kustomize build $OVERLAYS/staging |\
 
 configMap 名称的后缀是由 map 内容的哈希生成的 - 在这种情况下，名称后缀是 _k25m8k5k5m_ ：
 
-<!-- @grepStagingHash @test -->
+<!-- @grepStagingHash @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging | grep k25m8k5k5m
 ```
 
 现在修改 map patch ，更改该服务将使用的问候消息：
 
-<!-- @changeMap @test -->
+<!-- @changeMap @testAgainstLatestRelease -->
 ```
 sed -i.bak 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml
 ```
@@ -162,7 +162,7 @@ kustomize build $OVERLAYS/staging |\
 
 再次运行 kustomize 查看新的 configMap 名称：
 
-<!-- @grepStagingName @test -->
+<!-- @grepStagingName @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging |\
     grep -B 8 -A 1 staging-the-map
@@ -170,7 +170,7 @@ kustomize build $OVERLAYS/staging |\
 
 确认 configMap 内容的更改将会生成以 _cd7kdh48fd_ 结尾的三个新名称 - 一个在 configMap 的名称中，另两个在使用 ConfigMap 的 deployment 中：
 
-<!-- @countHashes @test -->
+<!-- @countHashes @testAgainstLatestRelease -->
 ```
 test 3 == \
   $(kustomize build $OVERLAYS/staging | grep cd7kdh48fd | wc -l); \
diff --git a/examples/zh/helloWorld.md b/examples/zh/helloWorld.md
index d54a4d76c8..e4a259313c 100644
--- a/examples/zh/helloWorld.md
+++ b/examples/zh/helloWorld.md
@@ -21,7 +21,7 @@
 
 首先创建一个工作空间：
 
-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -38,7 +38,7 @@ DEMO_HOME=$(mktemp -d)
 
 为了使本文档保持简洁，base 的资源位于补充目录中，并不在此处，请按照下面的方法下载它们：
 
-<!-- @downloadBase @test -->
+<!-- @downloadBase @testAgainstLatestRelease -->
 ```
 BASE=$DEMO_HOME/base
 mkdir -p $BASE
@@ -51,7 +51,7 @@ curl -s -o "$BASE/#1.yaml" "https://raw.githubusercontent.com\
 
 观察该目录：
 
-<!-- @runTree @test -->
+<!-- @runTree @testAgainstLatestRelease -->
 ```
 tree $DEMO_HOME
 ```
@@ -80,14 +80,14 @@ tree $DEMO_HOME
 
 `base` 目录中包含一个 [kustomization] 文件：
 
-<!-- @showKustomization @test -->
+<!-- @showKustomization @testAgainstLatestRelease -->
 ```
 more $BASE/kustomization.yaml
 ```
 
 （可选）在 base 目录上运行 `kustomize` 将定制过的 resources 打印到标准输出：
 
-<!-- @buildBase @test -->
+<!-- @buildBase @testAgainstLatestRelease -->
 ```
 kustomize build $BASE
 ```
@@ -96,14 +96,14 @@ kustomize build $BASE
 
 定制 _app label_ 并应用于所有的 resources ：
 
-<!-- @addLabel @test -->
+<!-- @addLabel @testAgainstLatestRelease -->
 ```
 sed -i.bak 's/app: hello/app: my-hello/' \
     $BASE/kustomization.yaml
 ```
 
 查看效果：
-<!-- @checkLabel @test -->
+<!-- @checkLabel @testAgainstLatestRelease -->
 ```
 kustomize build $BASE | grep -C 3 app:
 ```
@@ -116,7 +116,7 @@ kustomize build $BASE | grep -C 3 app:
  * _Production_ 包含更多的副本数。
  * 来自这些集群 [variants] 的问候消息将与来自其他集群的不同。
 
-<!-- @overlayDirectories @test -->
+<!-- @overlayDirectories @testAgainstLatestRelease -->
 ```
 OVERLAYS=$DEMO_HOME/overlays
 mkdir -p $OVERLAYS/staging
@@ -127,7 +127,7 @@ mkdir -p $OVERLAYS/production
 
 在 `staging` 目录中创建一个 kustomization 文件，用来定义一个新的名称前缀和一些不同的 labels 。
 
-<!-- @makeStagingKustomization @test -->
+<!-- @makeStagingKustomization @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$OVERLAYS/staging/kustomization.yaml
 namePrefix: staging-
@@ -149,7 +149,7 @@ EOF
 
 同时，将 _risky_ 标记设置为 true 。
 
-<!-- @stagingMap @test -->
+<!-- @stagingMap @testAgainstLatestRelease -->
 ```
 cat <<EOF >$OVERLAYS/staging/map.yaml
 apiVersion: v1
@@ -166,7 +166,7 @@ EOF
 
 在 `production` 目录中创建一个 kustomization 文件，用来定义一个新的名称前缀和 labels 。
 
-<!-- @makeProductionKustomization @test -->
+<!-- @makeProductionKustomization @testAgainstLatestRelease -->
 ```
 cat <<EOF >$OVERLAYS/production/kustomization.yaml
 namePrefix: production-
@@ -187,7 +187,7 @@ EOF
 
 因为生产环境需要处理更多的流量，新建一个 production patch 来增加副本数。
 
-<!-- @productionDeployment @test -->
+<!-- @productionDeployment @testAgainstLatestRelease -->
 ```
 cat <<EOF >$OVERLAYS/production/deployment.yaml
 apiVersion: apps/v1
@@ -210,7 +210,7 @@ EOF
 
 查看目录结构和差异：
 
-<!-- @listFiles @test -->
+<!-- @listFiles @testAgainstLatestRelease -->
 ```
 tree $DEMO_HOME
 ```
@@ -268,12 +268,12 @@ diff \
 
 输出不同 _overlys_ 的配置：
 
-<!-- @buildStaging @test -->
+<!-- @buildStaging @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging
 ```
 
-<!-- @buildProduction @test -->
+<!-- @buildProduction @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/production
 ```
diff --git a/examples/zh/jsonpatch.md b/examples/zh/jsonpatch.md
index d37a24cb19..4d218b8acc 100644
--- a/examples/zh/jsonpatch.md
+++ b/examples/zh/jsonpatch.md
@@ -6,7 +6,7 @@ kustomization文件支持通过[JSON patches](https://tools.ietf.org/html/rfc690
 
 首先，创建一个包含`ingress`的`kustomization`文件.
 
-<!-- @createIngress @test -->
+<!-- @createIngress @testAgainstLatestRelease -->
 ```bash
 DEMO_HOME=$(mktemp -d)
 
@@ -36,7 +36,7 @@ EOF
 - 把 host 从 `foo.bar.com` 改为 `foo.bar.io`
 - 把 servicePort 从 `80` 改为 `8080`
 
-<!-- @addJsonPatch @test -->
+<!-- @addJsonPatch @testAgainstLatestRelease -->
 ```bash
 cat <<EOF >$DEMO_HOME/ingress_patch.json
 [
@@ -48,7 +48,7 @@ EOF
 
 JSON patch 也可以写成 YAML 的格式.该例子顺便展示了“添加”操作：
 
-<!-- @addYamlPatch @test -->
+<!-- @addYamlPatch @testAgainstLatestRelease -->
 ```bash
 cat <<EOF >$DEMO_HOME/ingress_patch.yaml
 - op: replace
@@ -67,7 +67,7 @@ EOF
 
 在kustomization.yaml文件中增加 _patchesJson6902_ 字段，以应用该补丁
 
-<!-- @applyJsonPatch @test -->
+<!-- @applyJsonPatch @testAgainstLatestRelease -->
 ```bash
 cat <<EOF >>$DEMO_HOME/kustomization.yaml
 patchesJson6902:
@@ -82,7 +82,7 @@ EOF
 
 运行 `kustomize build $DEMO_HOME`, 在输出那里确认 host 已经被正确更新.
 
-<!-- @confirmHost @test -->
+<!-- @confirmHost @testAgainstLatestRelease -->
 ```bash
 test 1 == \
   $(kustomize build $DEMO_HOME | grep "host: foo.bar.io" | wc -l); \
@@ -91,7 +91,7 @@ test 1 == \
 
 运行 `kustomize build $DEMO_HOME`, 在输出那里确认 servicePort 已经被正确更新.
 
-<!-- @confirmServicePort @test -->
+<!-- @confirmServicePort @testAgainstLatestRelease -->
 
 ```bash
 test 1 == \
@@ -101,7 +101,7 @@ test 1 == \
 
 如果 patch 是YAML格式的，就能正确解析:
 
-<!-- @applyYamlPatch @test -->
+<!-- @applyYamlPatch @testAgainstLatestRelease -->
 ```bash
 cat <<EOF >>$DEMO_HOME/kustomization.yaml
 patchesJson6902:
@@ -116,7 +116,7 @@ EOF
 
 运行 `kustomize build $DEMO_HOME`, 在输出那里确认有 `/test` 这个路径.
 
-<!-- @confirmYamlPatch @test -->
+<!-- @confirmYamlPatch @testAgainstLatestRelease -->
 ```bash
 test 1 == \
   $(kustomize build $DEMO_HOME | grep "path: /test" | wc -l); \
diff --git a/travis/pre-commit.sh b/travis/pre-commit.sh
index ba34d5723a..195db86ec8 100755
--- a/travis/pre-commit.sh
+++ b/travis/pre-commit.sh
@@ -21,33 +21,64 @@ function runFunc {
   if [ $code -ne 0 ]; then
     result="FAILURE"
   fi
-  printf "============== end %s : %s code=%d\n\n\n" "$name" "$result" $code
+  printf "============== end %s : %s; exit code=%d\n\n\n" "$name" "$result" $code
 }
 
 function testGoLangCILint {
   golangci-lint run ./...
 }
 
-function testGoTest {
+function testGoTests {
   go test -v ./...
-}
 
-# These tests require the helm program, and at the moment
-# we're not asking travis to install helm.
-function testNoTravisGoTest {
-  go test -v sigs.k8s.io/kustomize/v3/pkg/target \
+  if [ -z ${TRAVIS+x} ]; then
+    echo " "
+    echo Not on travis, so running the notravis Go tests
+    echo " "
+    
+    # Requires helm.
+    # At the moment not asking travis to install it.
+    go test -v sigs.k8s.io/kustomize/v3/pkg/target \
       -run TestChartInflatorPlugin -tags=notravis
-  go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/chartinflator/... \
-    -run TestChartInflator -tags=notravis
-  mdrip --mode test --label helmtest README.md ./examples/chart.md
-  go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/validator/... \
+    go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/chartinflator/... \
+      -run TestChartInflator -tags=notravis
+
+    # Requires kubeeval.
+    # At the moment not asking travis to install it.
+    go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/validator/... \
        -run TestValidatorHappy -tags=notravis
-  go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/validator/... \
+    go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/validator/... \
        -run TestValidatorUnHappy -tags=notravis
+  fi
 }
 
-function testExamples {
-  mdrip --mode test --label test README.md ./examples
+function testExamplesAgainstLatestRelease {
+  /bin/rm -f $HOME/go/bin/kustomize
+  # Install latest release.
+  go get sigs.k8s.io/kustomize/v3/cmd/kustomize
+  PATH=$HOME/go/bin:$PATH \
+    mdrip --mode test --label testAgainstLatestRelease ./examples
+
+  if [ -z ${TRAVIS+x} ]; then
+    echo " "
+    echo Not on travis, so running the notravis example tests
+    echo " "
+
+    # Requires helm.  At the moment not asking travis to install it.
+    PATH=$HOME/go/bin:$PATH \
+      mdrip --mode test --label helmtest README.md ./examples/chart.md
+  fi
+}
+
+function testExamplesAgainstHead {
+  /bin/rm -f $HOME/go/bin/kustomize
+  # Install from head.
+  go install sigs.k8s.io/kustomize/v3/cmd/kustomize
+  # To test examples of unreleased features, add
+  # examples with code blocks annotated with some
+  # label _other than_ @testAgainstLatestRelease.
+  PATH=$HOME/go/bin:$PATH \
+    mdrip --mode test --label testAgainstLatestRelease ./examples
 }
 
 function generateCode {
@@ -100,15 +131,9 @@ echo "Working..."
 
 runFunc generateCode
 runFunc testGoLangCILint
-runFunc testGoTest
-
-if [ -z ${TRAVIS+x} ]; then
-  echo Not on travis, so running the notravis tests
-  runFunc testNoTravisGoTest
-fi
-
-PATH=$HOME/go/bin:$PATH
-runFunc testExamples
+runFunc testGoTests
+runFunc testExamplesAgainstLatestRelease
+runFunc testExamplesAgainstHead
 
 if [ $rc -eq 0 ]; then
   echo "SUCCESS!"