From 4294a0bdeb3bc1d36505f3528e746f8e15ac2c6b Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Wed, 7 Dec 2022 13:35:14 -0500
Subject: [PATCH 01/19] Changes to docs due to 0.20/1 deprecation

---
 contributing/single-sourcing-content.md       |   4 +-
 website/dbt-versions.js                       |   8 -
 website/docs/docs/build/incremental-models.md |   9 +-
 website/docs/docs/build/snapshots.md          |   4 +-
 .../cloud-choosing-a-dbt-version.md           |   7 +-
 .../docs/docs/dbt-versions/core-versions.md   |  40 ++---
 .../dbt-versions/upgrade-core-in-cloud.md     |   7 +-
 website/docs/docs/deploy/source-freshness.md  |   9 +-
 .../docs/get-started/connection-profiles.md   |   4 +-
 .../faqs/Project/properties-not-in-config.md  |   2 +-
 .../snapshotting-freshness-for-one-source.md  |   1 -
 website/docs/faqs/Tests/testing-sources.md    |   8 -
 .../docs/guides/legacy/understanding-state.md |   2 +-
 website/docs/reference/commands/build.md      |   6 -
 website/docs/reference/commands/deps.md       |   6 -
 website/docs/reference/commands/source.md     |  12 --
 .../docs/reference/configs-and-properties.md  |   6 +-
 .../reference/dbt-jinja-functions/dispatch.md |   4 -
 .../reference/dbt-jinja-functions/env_var.md  |   3 +-
 website/docs/reference/model-configs.md       |   4 -
 website/docs/reference/model-properties.md    |   4 -
 .../docs/reference/node-selection/defer.md    |  21 +--
 .../docs/reference/node-selection/exclude.md  |  11 --
 .../node-selection/graph-operators.md         |  34 ----
 .../docs/reference/node-selection/methods.md  | 115 +-------------
 .../node-selection/putting-it-together.md     |  25 ---
 .../reference/node-selection/set-operators.md |  39 -----
 .../state-comparison-caveats.md               |   6 +-
 .../docs/reference/node-selection/syntax.md   |  37 -----
 .../node-selection/test-selection-examples.md | 146 +-----------------
 .../node-selection/yaml-selectors.md          |  20 +--
 .../project-configs/dispatch-config.md        |   2 +-
 .../resource-configs/column_types.md          |   2 +-
 .../reference/resource-configs/fail_calc.md   |   7 -
 .../docs/reference/resource-configs/limit.md  |   7 -
 .../docs/reference/resource-configs/meta.md   |   6 -
 .../resource-configs/persist_docs.md          |   6 -
 .../resource-configs/quote_columns.md         |   2 -
 website/docs/reference/seed-configs.md        |   5 -
 website/docs/reference/seed-properties.md     |   5 +-
 website/docs/reference/snapshot-properties.md |   4 -
 website/docs/reference/test-configs.md        |   8 -
 website/snippets/core-versions-table.md       |   3 +-
 43 files changed, 44 insertions(+), 617 deletions(-)

diff --git a/contributing/single-sourcing-content.md b/contributing/single-sourcing-content.md
index 1c47b87b977..cf58c799999 100644
--- a/contributing/single-sourcing-content.md
+++ b/contributing/single-sourcing-content.md
@@ -90,7 +90,7 @@ This component can be added directly to a markdown file in a similar way as othe
 Both properties can be used together to set a range where the content should show. In the example below, this content will only show if the selected version is between **0.21** and **1.0**:
 
 ```markdown
-<VersionBlock firstVersion="0.21" lastVersion="1.0">
+<VersionBlock lastVersion="1.0">
 
 	Versioned content here
 
@@ -109,14 +109,12 @@ You see this block when the selected version is >= 0.21:
 
 ```markdown
 
-<VersionBlock firstVersion="0.21">
 
 ```shell
 $ dbt run --select [...] --defer --state path/to/artifacts
 $ dbt test --select [...] --defer --state path/to/artifacts
 \```
 
-</VersionBlock>
 ```
 
 You see this version block when the selected version is <= 0.20
diff --git a/website/dbt-versions.js b/website/dbt-versions.js
index 03f2721e42d..7000414bdfd 100644
--- a/website/dbt-versions.js
+++ b/website/dbt-versions.js
@@ -15,14 +15,6 @@ exports.versions = [
     version: "1.0",
     EOLDate: "2022-12-03"
   },
-  {
-    version: "0.21",
-    EOLDate: "2022-06-30"
-  },
-  {
-    version: "0.20",
-    EOLDate: "2022-06-30"
-  }
 ]
 
 exports.versionedPages = [
diff --git a/website/docs/docs/build/incremental-models.md b/website/docs/docs/build/incremental-models.md
index 08911764e32..c36431f7499 100644
--- a/website/docs/docs/build/incremental-models.md
+++ b/website/docs/docs/build/incremental-models.md
@@ -75,7 +75,7 @@ For more complex incremental models that make use of Common Table Expressions (C
 
 A `unique_key` determines whether a record has new values and should be updated. By using `unique_key`, you can ensure that each row from the source table is represented by a single row in your incremental model, without duplicates. Not specifying a `unique_key` will result in append-only behavior, which means dbt inserts all rows returned by the model's SQL into the preexisting target table without regard for whether the rows represent duplicates.
 
-<VersionBlock firstVersion="0.20" lastVersion="1.0">
+<VersionBlock lastVersion="1.0">
 
 This optional parameter for incremental models specifies a field that can uniquely identify each row within your model. You can define `unique_key` in a configuration block at the top of your model. If your model doesn't contain a single field that is unique, but rather a combination of columns, we recommend that you create a single column that can serve as unique identifier (by concatenating and hashing those columns), and pass it into your model's configuration.
 
@@ -272,13 +272,6 @@ select ...
 
 ### Strategy-specific configs
 
-<Changelog>
-
-  - **v0.20.0:** Introduced `merge_update_columns`
-  - **v0.21.0:** Introduced `on_schema_change`
-
-</Changelog>
-
 If you are using the `merge` strategy and have specified a `unique_key`, by default, dbt will entirely overwrite matched rows with new values.
 
 On adapters which support the `merge` strategy (including Snowflake, BigQuery, Apache Spark, and Databricks), you may optionally pass a list of column names to a `merge_update_columns` config. In that case, dbt will update _only_ the columns specified by the config, and keep the previous values of other columns.
diff --git a/website/docs/docs/build/snapshots.md b/website/docs/docs/build/snapshots.md
index a204c0416c5..3418d54c191 100644
--- a/website/docs/docs/build/snapshots.md
+++ b/website/docs/docs/build/snapshots.md
@@ -243,8 +243,6 @@ The `check` snapshot strategy can be configured to track changes to _all_ column
 
 ### Hard deletes (opt-in)
 
-<Changelog>New in v0.19.0</Changelog>
-
 Rows that are deleted from the source query are not invalidated by default. With the config option `invalidate_hard_deletes`, dbt can track rows that no longer exist. This is done by left joining the snapshot table with the source table, and filtering the rows that are still valid at that point, but no longer can be found in the source table. `dbt_valid_to` will be set to the current snapshot time.
 
 This configuration is not a different strategy as described above, but is an additional opt-in feature. It is not enabled by default since it alters the previous behavior.
@@ -294,7 +292,7 @@ A number of other configurations are also supported (e.g. `tags` and `post-hook`
 
 Snapshots can be configured from both your `dbt_project.yml` file and a `config` block, check out the [configuration docs](snapshot-configs) for more information.
 
-Note: As of v0.21, BigQuery users can use `target_project` and `target_dataset` as aliases for `target_database` and `target_schema`, respectively.
+Note: BigQuery users can use `target_project` and `target_dataset` as aliases for `target_database` and `target_schema`, respectively.
 
 
 ### Configuration best practices
diff --git a/website/docs/docs/dbt-cloud/cloud-configuring-dbt-cloud/cloud-choosing-a-dbt-version.md b/website/docs/docs/dbt-cloud/cloud-configuring-dbt-cloud/cloud-choosing-a-dbt-version.md
index c4a7e39d91c..2b8012d4b4d 100644
--- a/website/docs/docs/dbt-cloud/cloud-configuring-dbt-cloud/cloud-choosing-a-dbt-version.md
+++ b/website/docs/docs/dbt-cloud/cloud-configuring-dbt-cloud/cloud-choosing-a-dbt-version.md
@@ -32,12 +32,7 @@ We will continue to update this table so that customers know when we plan to sto
 
 <Snippet src="core-versions-table" />
 
-
-:::warning ⚠️ v0.X Non-Supported Period
- Accounts had until the end of June 2022 to upgrade to dbt 1.0 or later. Pre-dbt 1.0 versions will no longer receive patch fixes, and our support team will no longer assist with dbt version specific help on non-supported versions of dbt. Additionally, jobs running dbt versions prior to 1.0 may experience service disruptions before the end of the year and may be removed from the dbt Cloud context by year end. You will receive additional notification before any planned disruption to your production jobs.
-:::
-
-Starting in v1.0, dbt Cloud will ensure that you're always using the latest compatible patch release of `dbt-core` and plugins, including all the latest fixes. You may also choose to try prereleases of those patch releases before they are generally available.
+Starting with v1.0, dbt Cloud will ensure that you're always using the latest compatible patch release of `dbt-core` and plugins, including all the latest fixes. You may also choose to try prereleases of those patch releases before they are generally available.
 
 <!--- TODO: Include language to reflect:
   - notifying users when new minor versions are available
diff --git a/website/docs/docs/dbt-versions/core-versions.md b/website/docs/docs/dbt-versions/core-versions.md
index 3ba6bb75375..e1a0f68f0c6 100644
--- a/website/docs/docs/dbt-versions/core-versions.md
+++ b/website/docs/docs/dbt-versions/core-versions.md
@@ -4,7 +4,9 @@ id: "core"
 description: "Learn about semantic versioning for dbt Core, and how long those versions are supported."
 ---
 
-dbt Core releases follow [semantic versioning](https://semver.org/). The policies and expectations on this page assume prior familiarity with semantic versions. For more on how we use semantic versions, see [How dbt Core uses semantic versioning](#how-dbt-core-uses-semantic-versioning).
+dbt Core releases follow [semantic versioning](https://semver.org/) guidelines. For more on how we use semantic versions, see [How dbt Core uses semantic versioning](#how-dbt-core-uses-semantic-versioning).
+
+<Snippet src="core-versions-table" />
 
 ### Further reading
 
@@ -14,15 +16,13 @@ dbt Core releases follow [semantic versioning](https://semver.org/). The policie
 
 ## Version support prior to v1.0
 
-- We are no longer releasing new patches for minor versions prior to v1.0.
-- As of June 30, 2022, dbt Cloud will remove support for dbt Core versions older than v1.0. At that point, we will also remove v0.20 and v0.21 from the version dropdown on this website.
-- You can read the [specific version migration guides](/guides/migration/versions) to understand changes to each version. Each migration guide will link to pages of documentation that were added or updated. Those pages of documentation will also include "Changelog" notes, which you can toggle to see notes on specific changes from each older version.
+All dbt Core versions released prior to 1.0 and their version-specific documentation have been deprecated. If upgrading to a currently supported version, reference our [best practices for upgrading](#best-practices-for-upgrading)
 
-## Version support starting with v1.0
+## Current version support
 
-### Minor version support
+### Minor versions
 
-Minor versions include new features and capabilities. They will be supported for one year (12 months) from the date of their initial release. _This is a definite commitment._ Our mechanism for continuing to support a minor version is by releasing new patches: small, targeted bug fixes. Whenever we refer to a minor version, such as v1.0, we always mean its latest available patch release (v1.0.x).
+Minor versions include new features and capabilities. They will be supported for one year from the date of their initial release. _dbt Labs is committed to this 12 month support window._ Our mechanism for continuing to support a minor version is by releasing new patches: small, targeted bug fixes. Whenever we refer to a minor version, such as v1.0, we always mean its latest available patch release (v1.0.x).
 
 While a minor version is officially supported:
 - You can use it in dbt Cloud. For more on dbt Cloud versioning, see [Choosing a dbt version](cloud-choosing-a-dbt-version).
@@ -30,7 +30,7 @@ While a minor version is officially supported:
 
 ### Ongoing patches
 
-During the 12 months of ongoing support, we will continue to release new patch versions that include fixes.
+During the 12 month support window, we will continue to release new patch versions that include fixes.
 
 **Active Support:** In the first few months after a minor version's initial release, we will patch it with "bugfix" releases. These will include fixes for regressions and net-new bugs that were present in the minor version's original release.
 
@@ -42,12 +42,6 @@ After a minor version reaches the end of its critical support period, one year a
 
 We aim to release a new minor "feature" every 3 months. _This is an indicative timeline ONLY._ For the latest information about upcoming releases, including their planned release dates and which features and fixes might be included in each, always consult the [`dbt-core` repository milestones](https://github.com/dbt-labs/dbt-core/milestones).
 
-<Snippet src="core-versions-table" />
-
-:::warning ⚠️ v0.X Non-Supported Period
-We are giving accounts until the end of June 2022 to upgrade to dbt 1.0 or later. Pre-dbt 1.0 versions will not receive patch fixes, and our support team will no longer assist with dbt version specific help on non-supported versions of dbt. Additionally, jobs running dbt versions prior to 1.0 will start experiencing service disruptions before the end of the year 2022 and will be removed from the dbt Cloud context by end of the year 2022. You will receive additional email and in app notification before disruption to your production jobs.
-:::
-
 ## Best practices for upgrading
 
 Because of our new version practice, we've outlined best practices and expectations for dbt users to upgrade as we continue to release new versions of dbt Core.
@@ -58,7 +52,7 @@ We expect users to upgrade to patches as soon as they're available. When we refe
 
 ### Upgrading to new minor versions
 
-You may continue to use any minor version of dbt while it is officially supported. During that period, it will remain available in dbt Cloud, and in the version dropdown on this website. While we do not expect users to immediately upgrade to newer minor versions as soon as they're available, there will always be some features and fixes that are only available for users of the latest minor version.
+During the official support window period, minor versions will remain available in dbt Cloud, and in the version dropdown on the docs site. While we do not expect users to immediately upgrade to newer minor versions as soon as they're available, there will always be some features and fixes that are only available for users of the latest minor version.
 
 ### Trying prereleases
 
@@ -68,7 +62,7 @@ All dbt Core versions are available as _prereleases_ before the final release. "
 
 Like many software projects, dbt Core releases follow [semantic versioning](https://semver.org/), which defines three types of version releases.
 
-- **Major versions:** To date, dbt Core has had one major version release: v1.0.0. When v2.0.0 is released, it will introduce new features and break backwards compatibility for functionality that has been deprecated.
+- **Major versions:** To date, dbt Core has had one major version release: v1.0.0. When v2.0.0 is released, it will introduce new features and backwards compatibility for functionality that has been deprecated will no longer work.
 - **Minor versions**, also called "feature" releases, include a mix of new features, behind-the-scenes improvements, and changes to existing capabilities that are **backwards compatible** with previous minor versions. They will not break code in your project that relies on documented functionality.
 - **Patch versions**, also called "bugfix" or "security" releases, include **fixes _only_**. These fixes could be needed to restore previous (documented) behavior, fix obvious shortcomings of new features, or offer critical fixes for security or installation issues. We are judicious about which fixes are included in patch releases, to minimize the surface area of changes.
 
@@ -78,21 +72,21 @@ We are committed to avoiding breaking changes in minor versions for end users of
 
 ### How we version adapter plugins
 
-When you use dbt, you're using `dbt-core` together with an adapter plugin specific to your database. You can see the current list in [Supported Data Platforms](supported-data-platforms). Both `dbt-core` and dbt adapter plugins follow semantic versioning.
+When you use dbt, you use a combination of `dbt-core` and an adapter plugin specific to your database. You can see the current list in [Supported Data Platforms](supported-data-platforms). Both `dbt-core` and dbt adapter plugins follow semantic versioning.
 
-`dbt-core` and adapter plugins coordinate new features and behind-the-scenes changes in minor releases. When it comes to fixing bugs, sooner is better—so patch versions are released independently for `dbt-core` and plugins.
+`dbt-core` and adapter plugins coordinate new features and behind-the-scenes changes in minor releases. When fixing bugs, sooner is better, so patch versions are released independently for `dbt-core` and plugins.
 
-What does that mean? Patch version numbers are likely to be different between `dbt-core` and the adapter plugin(s) you have installed. Major and minor version numbers should always match.
+That means that patch version numbers will likely differ between `dbt-core` and the adapter plugin(s) you have installed. However, major and minor version numbers should always match.
 
-As an example, on March 1, you may find you're using `dbt-core==1.0.3` with `dbt-snowflake==1.0.0`. The most important thing is that you're using the latest patch available for each (v1.0.x). If you're running dbt locally, you can use the `dbt --version` command to see which versions you have installed:
+For example, you may find you're using `dbt-core==1.2.3` with `dbt-snowflake==1.2.0`. It is critical that you're using the latest patch available for both core and the adapter (v1.2.x). Use the `dbt --version` command to see which versions you have installed:
 ```
 $ dbt --version
-installed version: 1.0.3
-   latest version: 1.0.3
+installed version: 1.2.3
+   latest version: 1.2.3
 
 Up to date!
 
 Plugins:
-  - snowflake: 1.0.0 - Up to date!
+  - snowflake: 1.2.0 - Up to date!
 ```
 It's likely that newer patches have become available since then, so it's always important to check and make sure you're up to date!
diff --git a/website/docs/docs/dbt-versions/upgrade-core-in-cloud.md b/website/docs/docs/dbt-versions/upgrade-core-in-cloud.md
index f0b99499891..fe173589613 100644
--- a/website/docs/docs/dbt-versions/upgrade-core-in-cloud.md
+++ b/website/docs/docs/dbt-versions/upgrade-core-in-cloud.md
@@ -35,12 +35,7 @@ We will continue to update this table so that customers know when we plan to sto
 
 <Snippet src="core-versions-table" />
 
-
-:::warning ⚠️ v0.X Non-Supported Period
- Accounts had until the end of June 2022 to upgrade to dbt 1.0 or later. Pre-dbt 1.0 versions will no longer receive patch fixes, and our support team will no longer assist with dbt version specific help on non-supported versions of dbt. Additionally, jobs running dbt versions prior to 1.0 may experience service disruptions before the end of the year and may be removed from the dbt Cloud context by year end. You will receive additional notification before any planned disruption to your production jobs.
-:::
-
-Starting in v1.0, dbt Cloud will ensure that you're always using the latest compatible patch release of `dbt-core` and plugins, including all the latest fixes. You may also choose to try prereleases of those patch releases before they are generally available.
+Starting with v1.0, dbt Cloud will ensure that you're always using the latest compatible patch release of `dbt-core` and plugins, including all the latest fixes. You may also choose to try prereleases of those patch releases before they are generally available.
 
 <!--- TODO: Include language to reflect:
   - notifying users when new minor versions are available
diff --git a/website/docs/docs/deploy/source-freshness.md b/website/docs/docs/deploy/source-freshness.md
index 5056e258eda..b7c63955307 100644
--- a/website/docs/docs/deploy/source-freshness.md
+++ b/website/docs/docs/deploy/source-freshness.md
@@ -14,14 +14,7 @@ dbt Cloud provides a helpful interface around dbt's [source data freshness](/doc
 
 First, make sure to configure your sources to [snapshot freshness information](/docs/build/sources#snapshotting-source-data-freshness).
 
-<Changelog>
-
-  - **v0.21.0:** Renamed `dbt source snapshot-freshness` to `dbt source freshness`. If using an older version of dbt, the command is `snapshot-freshness`.  
-  To have dbt Cloud display data source freshness as a rendered user interface, you will still need to use the pre-v0.21 syntax of `dbt source snapshot-freshness`.
-
-</Changelog>
-
-Then, to enable source freshness snapshots in dbt Cloud, add a `dbt source freshness` step to one of your jobs, or create a new job to snapshot source freshness. **Note:** If you're using an older version of dbt Core (before v0.21), you'll need to use the old name of this command instead: `dbt source snapshot-freshness`. See [`source` command docs](commands/source) for details.
+Then, to enable source freshness snapshots in dbt Cloud, add a `dbt source freshness` step to one of your jobs, or create a new job to snapshot source freshness.
 
 <Lightbox src="/img/docs/dbt-cloud/using-dbt-cloud/job-step-source-freshness.png" title="Adding a step to snapshot source freshness"/>
 
diff --git a/website/docs/docs/get-started/connection-profiles.md b/website/docs/docs/get-started/connection-profiles.md
index ffb69b19c97..54d5f5f3249 100644
--- a/website/docs/docs/get-started/connection-profiles.md
+++ b/website/docs/docs/get-started/connection-profiles.md
@@ -25,7 +25,7 @@ profile: 'jaffle_shop'
 
 dbt then checks your `profiles.yml` file for a profile with the same name. A profile contains all the details required to connect to your data warehouse.
 
-<VersionBlock firstVersion="0.20" lastVersion="1.2">
+<VersionBlock lastVersion="1.2">
 
 By default, dbt expects the `profiles.yml` file to be located in the `~/.dbt/` directory.
 
@@ -157,7 +157,7 @@ You can use a different number of threads than the value defined in your target
 
 The parent directory for `profiles.yml` is determined using the following precedence:
 
-<VersionBlock firstVersion="0.20"  lastVersion="1.2">
+<VersionBlock lastVersion="1.2">
 
 1. `--profiles-dir` option
 1. `DBT_PROFILES_DIR` environment variable
diff --git a/website/docs/faqs/Project/properties-not-in-config.md b/website/docs/faqs/Project/properties-not-in-config.md
index 9e334c55ce3..574540719c3 100644
--- a/website/docs/faqs/Project/properties-not-in-config.md
+++ b/website/docs/faqs/Project/properties-not-in-config.md
@@ -6,7 +6,7 @@ id: properties-not-in-config
 
 ---
 
-In v0.21, dbt added the ability to define node configs in `.yml` files, in addition to `config()` blocks and `dbt_project.yml`. But the reverse isn't always true: there are some things in `.yml` files that can _only_ be defined there.
+dbt has the ability to define node configs in `.yml` files, in addition to `config()` blocks and `dbt_project.yml`. But the reverse isn't always true: there are some things in `.yml` files that can _only_ be defined there.
 
 Certain properties are special, because:
 - They have a unique Jinja rendering context
diff --git a/website/docs/faqs/Snapshots/snapshotting-freshness-for-one-source.md b/website/docs/faqs/Snapshots/snapshotting-freshness-for-one-source.md
index c1cc7687b11..1cdba2da0d5 100644
--- a/website/docs/faqs/Snapshots/snapshotting-freshness-for-one-source.md
+++ b/website/docs/faqs/Snapshots/snapshotting-freshness-for-one-source.md
@@ -6,7 +6,6 @@ id: snapshotting-freshness-for-one-source
 
 ---
 
-:::info As of dbt Core v0.21, you need to prefix sources with the source: selection method. In previous versions of dbt, sources were specified by name only. :::
 
 Use the `--select` flag to snapshot freshness for specific sources. Eg:
 
diff --git a/website/docs/faqs/Tests/testing-sources.md b/website/docs/faqs/Tests/testing-sources.md
index 06051eae7e9..fc93ba5518c 100644
--- a/website/docs/faqs/Tests/testing-sources.md
+++ b/website/docs/faqs/Tests/testing-sources.md
@@ -27,11 +27,3 @@ $ dbt test --select source:jaffle_shop.orders
 ```
 
 Yep, we know this syntax is a little less than ideal, so we're hoping to improve it in a future release. Check out the [model selection syntax](node-selection/syntax) for more examples!
-
-
-:::info Node selection syntax 
-In dbt 0.21.0, the node selection syntax [was standardized](https://github.com/dbt-labs/dbt-core/pull/3791) to use `--select` everywhere. Before this, some commands like `dbt run` and `dbt test` used `--models` instead.  
-
-Older versions still show an error because [argparse](https://docs.python.org/3/library/argparse.html#allow-abbrev) is expanding `--select` to `--selector`, which is a different flag.
-To fix this issue, either upgrade to dbt 0.21.0 or higher, or use `--models` instead of `--select`.
-:::
diff --git a/website/docs/guides/legacy/understanding-state.md b/website/docs/guides/legacy/understanding-state.md
index dadcfd3a23d..7ed88f586e6 100644
--- a/website/docs/guides/legacy/understanding-state.md
+++ b/website/docs/guides/legacy/understanding-state.md
@@ -41,7 +41,7 @@ Another element of job state is the `result` of a prior dbt invocation. After ex
 The following dbt commands produce `run_results.json` artifacts whose results can be referenced in subsequent dbt invocations:  
 - `dbt run`
 - `dbt test`
-- `dbt build` (new in dbt version v0.21.0)
+- `dbt build`
 - `dbt seed` 
 
 After issuing one of the above commands, you can reference the results by adding a selector to a subsequent command as follows: 
diff --git a/website/docs/reference/commands/build.md b/website/docs/reference/commands/build.md
index 50b443246c3..417241c44e3 100644
--- a/website/docs/reference/commands/build.md
+++ b/website/docs/reference/commands/build.md
@@ -3,12 +3,6 @@ title: "build"
 id: "build"
 ---
 
-<Changelog>
-
-- Introduced in **v0.21.0**
-    
-</Changelog>
-
 The `dbt build` command will:
 - run models
 - test tests
diff --git a/website/docs/reference/commands/deps.md b/website/docs/reference/commands/deps.md
index a52f07bb934..42023b56887 100644
--- a/website/docs/reference/commands/deps.md
+++ b/website/docs/reference/commands/deps.md
@@ -5,12 +5,6 @@ id: "deps"
 
 `dbt deps` pulls the most recent version of the dependencies listed in your `packages.yml` from git. See [Package-Management](/docs/build/packages) for more information.
 
-<Changelog>
-
-- **v0.21.0**: dbt package version comparison logging is new!
-
-</Changelog>
-
 Where relevant, dbt will display up to date and/or latest versions of packages that are listed on dbt Hub. Example below.
 
 > This does NOT apply to packages that are installed via git/local
diff --git a/website/docs/reference/commands/source.md b/website/docs/reference/commands/source.md
index 230b92669a1..37d1236aa62 100644
--- a/website/docs/reference/commands/source.md
+++ b/website/docs/reference/commands/source.md
@@ -11,22 +11,10 @@ If you're using an older version of dbt Core (before v0.21), the old name of the
 
 ### dbt source freshness
 
-<Changelog>
-
-  - **v0.21.0:** Renamed `dbt source snapshot-freshness` to `dbt source freshness`. If using an older version of dbt, the command is `snapshot-freshness`.
-
-</Changelog>
-
 If your dbt project is [configured with sources](/docs/build/sources), then the `dbt source freshness` command will query all of your defined source tables, determining the "freshness" of these tables. If the tables are stale (based on the `freshness` config specified for your sources) then dbt will report a warning or error accordingly. If a source <Term id="table" /> is in a stale state, then dbt will exit with a nonzero exit code.
 
 ### Specifying sources to snapshot
 
-<Changelog>
-
-  - **v0.21.0:** Selection syntax for the `freshness` task now mirrors other tasks. Sources need to be prefixed with the `source:` selection method. In previous versions of dbt, sources were specified by name only.
-
-</Changelog>
-
 By default, `dbt source freshness` will calculate freshness information for all of the sources in your project. To snapshot freshness for a subset of these sources, use the `--select` flag.
 
 ```bash
diff --git a/website/docs/reference/configs-and-properties.md b/website/docs/reference/configs-and-properties.md
index 436f06f704d..af213075093 100644
--- a/website/docs/reference/configs-and-properties.md
+++ b/website/docs/reference/configs-and-properties.md
@@ -2,10 +2,6 @@
 title: Configs, properties, what are they?
 ---
 
-<Changelog>
-    - **v0.21.0** introduced the `config` property, thereby allowing you to configure certain resource types in all `.yml` files
-</Changelog>
-
 Resources in your project—models, snapshots, seeds, tests, and the rest—can have a number of declared **properties**. Resources can also define **configurations**, which are a special kind of property that bring extra abilities. What's the distinction?
 - Properties are declared for resources one-by-one in `.yml` files. Configs can be defined there, nested under a `config` property. They can also be set one-by-one via a `config()` macro (right within `.sql` files), and for many resources at once in `dbt_project.yml`.
 - Because configs can be set in multiple places, they are also applied hierarchically. An individual resource might _inherit_ or _override_ configs set elsewhere.
@@ -68,7 +64,7 @@ Previous versions of the docs referred to these as `schema.yml` files — we've
 
 ### Which properties are _not_ also configs?
 
-In v0.21, dbt added the ability to define node configs in `.yml` files, in addition to `config()` blocks and `dbt_project.yml`. But the reverse isn't always true: there are some things in `.yml` files that can _only_ be defined there.
+dbt has the ability to define node configs in `.yml` files, in addition to `config()` blocks and `dbt_project.yml`. But the reverse isn't always true: there are some things in `.yml` files that can _only_ be defined there.
 
 Certain properties are special, because:
 - They have a unique Jinja rendering context
diff --git a/website/docs/reference/dbt-jinja-functions/dispatch.md b/website/docs/reference/dbt-jinja-functions/dispatch.md
index 46f17029fef..115805406e8 100644
--- a/website/docs/reference/dbt-jinja-functions/dispatch.md
+++ b/website/docs/reference/dbt-jinja-functions/dispatch.md
@@ -4,10 +4,6 @@ title: "dispatch"
 
 <Changelog>
 
-- **v0.18.0:** Introduced `dispatch` as a replacement for deprecated `adapter_macro`
-- **v0.19.2:** Limited rendering context for `dispatch` arguments. Includes backwards compatibility for widely used packages.
-- **v0.20.0:** Parent adapters' macro implementations are included in search order. Formalized supported arguments.
-- **v0.21.0:** All dispatched macros in the dbt global project include `dbt` namespace
 - **v1.0.0:** The 'packages' argument is fully deprecated. Use `macro_namespace` and project-level `dispatch` config instead.
 
 </Changelog>
diff --git a/website/docs/reference/dbt-jinja-functions/env_var.md b/website/docs/reference/dbt-jinja-functions/env_var.md
index b956ece728a..b958a0d24f8 100644
--- a/website/docs/reference/dbt-jinja-functions/env_var.md
+++ b/website/docs/reference/dbt-jinja-functions/env_var.md
@@ -58,8 +58,7 @@ models:
 
 <Changelog>
 
-  - **v0.21.0:** Introduced `DBT_ENV_SECRET_` and log scrubbing
-  - **v1.0.0:** Restricted use of secret env vars to `profiles.yml` and `packages.yml`
+  **v1.0.0:** Restricted use of secret env vars to `profiles.yml` and `packages.yml`
 
 </Changelog>
 
diff --git a/website/docs/reference/model-configs.md b/website/docs/reference/model-configs.md
index 87027448cfe..668856b6bdb 100644
--- a/website/docs/reference/model-configs.md
+++ b/website/docs/reference/model-configs.md
@@ -2,10 +2,6 @@
 title: Model configurations
 ---
 
-<Changelog>
-    - **v0.21.0** introduced the `config` property, thereby allowing you to configure models in all `.yml` files
-</Changelog>
-
 ## Related documentation
 * [Models](/docs/build/models)
 * [`run` command](run)
diff --git a/website/docs/reference/model-properties.md b/website/docs/reference/model-properties.md
index 1e1bb5e7ecf..c49f0f7d80b 100644
--- a/website/docs/reference/model-properties.md
+++ b/website/docs/reference/model-properties.md
@@ -2,10 +2,6 @@
 title: Model properties
 ---
 
-<Changelog>
-    - **v0.21.0** introduced the `config` property, thereby allowing you to configure models in all `.yml` files
-</Changelog>
-
 Models properties can be declared in `.yml` files in your `models/` directory (as defined by the [`model-paths` config](model-paths)).
 
 You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in subfolders within the `models/` directory.
diff --git a/website/docs/reference/node-selection/defer.md b/website/docs/reference/node-selection/defer.md
index f5a6d5e5c0c..7c9960e19a6 100644
--- a/website/docs/reference/node-selection/defer.md
+++ b/website/docs/reference/node-selection/defer.md
@@ -16,24 +16,11 @@ Defer is a powerful feature that makes it possible to run a subset of models or
 Defer requires that a manifest from a previous dbt invocation be passed to the `--state` flag or env var. Together with the `state:` selection method, these features enable "Slim CI". Read more about [state](understanding-state).
 ### Usage
 
-<VersionBlock firstVersion="0.21">
-
 ```shell
 $ dbt run --select [...] --defer --state path/to/artifacts
 $ dbt test --select [...] --defer --state path/to/artifacts
 ```
 
-</VersionBlock>
-
-<VersionBlock lastVersion="0.20">
-
-```shell
-$ dbt run --models [...] --defer --state path/to/artifacts
-$ dbt test --models [...] --defer --state path/to/artifacts
-```
-
-</VersionBlock>
-
 When the `--defer` flag is provided, dbt will resolve `ref` calls differently depending on two criteria:
 1. Is the referenced node included in the model selection criteria of the current run?
 2. Does the reference node exist as a database object in the current environment?
@@ -72,9 +59,7 @@ group by 1
 I want to test my changes. Nothing exists in my development schema, `dev_alice`.
 
 ### test
-:::info
-Before dbt v0.21, use the `--models` flag instead of `--select`.
-:::
+
 </File>
 
 <Tabs
@@ -160,10 +145,6 @@ models:
 
 (A bit silly, since all the data in `model_b` had to come from `model_a`, but suspend your disbelief.)
 
-:::info
-Before dbt v0.21, use the `--models` flag instead of `--select`.
-:::
-
 </File>
 
 <Tabs
diff --git a/website/docs/reference/node-selection/exclude.md b/website/docs/reference/node-selection/exclude.md
index 4fbc1a6e79e..9fd146fc104 100644
--- a/website/docs/reference/node-selection/exclude.md
+++ b/website/docs/reference/node-selection/exclude.md
@@ -5,21 +5,10 @@ title: "Exclude"
 ### Excluding models
 dbt provides an `--exclude` flag with the same semantics as `--select`. Models specified with the `--exclude` flag will be removed from the set of models selected with `--select`.
 
-<VersionBlock firstVersion="0.21">
-
 ```bash
 $ dbt run --select my_package.*+ --exclude my_package.a_big_model+
 ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-```bash
-$ dbt run --models my_package.*+ --exclude my_package.a_big_model+
-```
-
-</VersionBlock>
-
 Exclude a specific resource by its name or lineage:
 
 ```bash
diff --git a/website/docs/reference/node-selection/graph-operators.md b/website/docs/reference/node-selection/graph-operators.md
index 31318b1379a..1e7c88fadfc 100644
--- a/website/docs/reference/node-selection/graph-operators.md
+++ b/website/docs/reference/node-selection/graph-operators.md
@@ -5,7 +5,6 @@ title: "Graph operators"
 ### The "plus" operator
 If placed at the front of the model selector, `+` will select all parents of the selected model. If placed at the end of the string, `+` will select all children of the selected model.
 
-<VersionBlock firstVersion="0.21">
 
    ```bash
   $ dbt run --select my_model+          # select my_model and all children
@@ -13,24 +12,12 @@ If placed at the front of the model selector, `+` will select all parents of the
   $ dbt run --select +my_model+         # select my_model, and all of its parents and children
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt run --models my_model+          # select my_model and all children
-  $ dbt run --models +my_model          # select my_model and all parents
-  $ dbt run --models +my_model+         # select my_model, and all of its parents and children
-  ```
-
-</VersionBlock>
 
 ### The "n-plus" operator
-<Changelog>New in v0.18.0</Changelog>
 
 You can adjust the behavior of the `+` operator by quantifying the number of edges
 to step through.
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt run --select my_model+1          # select my_model and its first-degree children
@@ -38,16 +25,6 @@ to step through.
   $ dbt run --select 3+my_model+4        # select my_model, its parents up to the 3rd degree, and its children down to the 4th degree
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt run --models my_model+1          # select my_model and its first-degree children
-  $ dbt run --models 2+my_model          # select my_model, its first-degree parents, and its second-degree parents ("grandparents")
-  $ dbt run --models 3+my_model+4        # select my_model, its parents up to the 3rd degree, and its children down to the 4th degree
-  ```
-
-</VersionBlock>
 
 ### The "at" operator
 The `@` operator is similar to `+`, but will also include _the parents of the children of the selected model_. This is useful in continuous integration environments where you want to build a model and all of its children, but the _parents_ of those children might not exist in the database yet. The selector `@snowplow_web_page_context` will build all three models shown in the diagram below.
@@ -61,19 +38,8 @@ $ dbt run --models @my_model          # select my_model, its children, and the p
 ### The "star" operator
 The `*` operator matches all models within a package or directory.
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt run --select snowplow.*      # run all of the models in the snowplow package
   $ dbt run --select finance.base.*  # run all of the models in models/finance/base
   ```
-
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt run --models snowplow.*      # run all of the models in the snowplow package
-  $ dbt run --models finance.base.*  # run all of the models in models/finance/base
-  ```
-
-</VersionBlock>
diff --git a/website/docs/reference/node-selection/methods.md b/website/docs/reference/node-selection/methods.md
index 43c0fe1b628..7288cc2e270 100644
--- a/website/docs/reference/node-selection/methods.md
+++ b/website/docs/reference/node-selection/methods.md
@@ -8,45 +8,26 @@ syntax `method:value`.
 ### The "tag" method
 The `tag:` method is used to select models that match a specified [tag](resource-configs/tags).
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt run --select tag:nightly    # run all models with the `nightly` tag
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt run --models tag:nightly    # run all models with the `nightly` tag
-  ```
-
-</VersionBlock>
 
 ### The "source" method
 The `source` method is used to select models that select from a specified [source](/docs/build/sources#using-sources). Use in conjunction with the `+` operator.
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt run --select source:snowplow+    # run all models that select from Snowplow sources
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt run --models source:snowplow+    # run all models that select from Snowplow sources
-  ```
-
-</VersionBlock>
 
 ### The "path" method
 The `path` method is used to select models located at or under a specific path.
 While the `path` prefix is not explicitly required, it may be used to make
 selectors unambiguous.
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   # These two selectors are equivalent
@@ -58,20 +39,6 @@ selectors unambiguous.
   dbt run --select models/staging/github/stg_issues.sql
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  # These two selectors are equivalent
-  dbt run --models path:models/staging/github
-  dbt run --models models/staging/github
-
-  # These two selectors are equivalent
-  dbt run --models path:models/staging/github/stg_issues.sql
-  dbt run --models models/staging/github/stg_issues.sql
-  ```
-
-</VersionBlock>
 
 <VersionBlock firstVersion="1.2">
 
@@ -87,13 +54,11 @@ dbt run --select some_model
 </VersionBlock>
 
 ### The "package" method
-<Changelog>New in v0.18.0</Changelog>
 
 The `package` method is used to select models defined within the root project
 or an installed dbt package. While the `package:` prefix is not explicitly required, it may be used to make
 selectors unambiguous.
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   # These three selectors are equivalent
@@ -102,24 +67,12 @@ selectors unambiguous.
   dbt run --select snowplow.*
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  # These three selectors are equivalent
-  dbt run --models package:snowplow
-  dbt run --models snowplow
-  dbt run --models snowplow.*
-  ```
-
-</VersionBlock>
 
 ### The "config" method
-<Changelog>New in v0.18.0</Changelog>
 
 The `config` method is used to select models that match a specified [node config](configs-and-properties).
 
-<VersionBlock firstVersion="0.21">
+
 
   ```bash
   $ dbt run --select config.materialized:incremental    # run all models that are materialized incrementally
@@ -127,16 +80,6 @@ The `config` method is used to select models that match a specified [node config
   $ dbt run --select config.cluster_by:geo_country      # run all models clustered by `geo_country`
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt run --models config.materialized:incremental    # run all models that are materialized incrementally
-  $ dbt run --models config.schema:audit                # run all models that are created in the `audit` schema
-  $ dbt run --models config.cluster_by:geo_country      # run all models clustered by `geo_country`
-  ```
-
-</VersionBlock>
 
 <VersionBlock firstVersion="1.3">
 
@@ -166,39 +109,25 @@ $ dbt ls -s config.transient:true
 
 ### The "test_type" method
 <Changelog>
-
-- New in v0.18.0
-- In v1.0.0, test types were renamed: "singular" (instead of "data") and "generic" (instead of "schema")
-
+In v1.0.0, test types were renamed: "singular" (instead of "data") and "generic" (instead of "schema")
 </Changelog>
 
 The `test_type` method is used to select tests based on their type, `singular` or `generic`:
 
-<VersionBlock firstVersion="0.21">
+
 
   ```bash
   $ dbt test --select test_type:generic        # run all generic tests
   $ dbt test --select test_type:singular       # run all singular tests
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt test --models test_type:schema        # run all schema tests
-  $ dbt test --models test_type:data          # run all data tests
-  ```
-
-</VersionBlock>
 
 ### The "test_name" method
-<Changelog>New in v0.18.0</Changelog>
 
 The `test_name` method is used to select tests based on the name of the generic test
 that defines it. For more information about how generic tests are defined, read about
 [tests](/docs/build/tests).
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt test --select test_name:unique            # run all instances of the `unique` test
@@ -206,22 +135,8 @@ that defines it. For more information about how generic tests are defined, read
   $ dbt test --select test_name:range_min_max     # run all instances of a custom schema test defined in the local project, `range_min_max`
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt test --models test_name:unique            # run all instances of the `unique` test
-  $ dbt test --models test_name:equality          # run all instances of the `dbt_utils.equality` test
-  $ dbt test --models test_name:range_min_max     # run all instances of a custom schema test defined in the local project, `range_min_max`
-  ```
-
-</VersionBlock>
 
 ### The "state" method
-<Changelog>
-    - **v0.18.0** introduced `state:new` and `state:modified`
-    - **v0.21.0** introduced `modified` sub-selectors, and handling for upstream macro dependencies
-</Changelog>
 
 **N.B.** State-based selection is a powerful, complex feature. Read about [known caveats and limitations](node-selection/state-comparison-caveats) to state comparison.
 
@@ -231,7 +146,6 @@ The `state` method is used to select nodes by comparing them against a previous
 
 `state:modified`: All new nodes, plus any changes to existing nodes.
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt test --select state:new            # run all tests on new models + and new tests on old models
@@ -239,16 +153,6 @@ The `state` method is used to select nodes by comparing them against a previous
   $ dbt ls --select state:modified         # list all modified nodes (not just models)
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt test --models state:new            # run all tests on new models + and new tests on old models
-  $ dbt run --models state:modified        # run all models that have been modified
-  $ dbt ls --select state:modified         # This really is still --select! list all modified nodes (not just models)
-  ```
-
-</VersionBlock>
 
 Because state comparison is complex, and everyone's project is different, dbt supports subselectors that include a subset of the full `modified` criteria:
 - `state:modified.body`: Changes to node body (e.g. model SQL, seed values)
@@ -260,11 +164,9 @@ Because state comparison is complex, and everyone's project is different, dbt su
 Remember that `state:modified` includes _all_ of the criteria above, as well as some extra resource-specific criteria, such as modifying a source's `freshness` or `quoting` rules or an exposure's `maturity` property. (View the source code for the full set of checks used when comparing [sources](https://github.com/dbt-labs/dbt-core/blob/9e796671dd55d4781284d36c035d1db19641cd80/core/dbt/contracts/graph/parsed.py#L660-L681), [exposures](https://github.com/dbt-labs/dbt-core/blob/9e796671dd55d4781284d36c035d1db19641cd80/core/dbt/contracts/graph/parsed.py#L768-L783), and [executable nodes](https://github.com/dbt-labs/dbt-core/blob/9e796671dd55d4781284d36c035d1db19641cd80/core/dbt/contracts/graph/parsed.py#L319-L330).)
 
 ### The "exposure" method
-<Changelog>New in v0.18.1</Changelog>
 
 The `exposure` method is used to select parent resources of a specified [exposure](exposures). Use in conjunction with the `+` operator.
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt run --select +exposure:weekly_kpis                # run all models that feed into the weekly_kpis exposure
@@ -272,17 +174,6 @@ The `exposure` method is used to select parent resources of a specified [exposur
   $ dbt ls --select +exposure:* --resource-type source    # list all sources upstream of all exposures
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt run --models +exposure:weekly_kpis                # run all models that feed into the weekly_kpis exposure
-  $ dbt test --models +exposure:*                         # test all resources upstream of all exposures
-  $ dbt ls --select +exposure:* --resource-type source    # This really is still --select! list all sources upstream of all exposures
-  ```
-
-</VersionBlock>
-
 ### The "metric" method
 <Changelog>New in v1.0.0</Changelog>
 
diff --git a/website/docs/reference/node-selection/putting-it-together.md b/website/docs/reference/node-selection/putting-it-together.md
index c8be96142d0..8faf02e6cc9 100644
--- a/website/docs/reference/node-selection/putting-it-together.md
+++ b/website/docs/reference/node-selection/putting-it-together.md
@@ -2,7 +2,6 @@
 title: "Putting it together"
 ---
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt run --select my_package.*+      # select all models in my_package and their children
@@ -16,40 +15,16 @@ title: "Putting it together"
   $ dbt test --select config.incremental_strategy:insert_overwrite,test_name:unique   # execute all `unique` tests that select from models using the `insert_overwrite` incremental strategy
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
 
-  ```bash
-  $ dbt run --models my_package.*+      # select all models in my_package and their children
-  $ dbt run --models +some_model+       # select some_model and all parents and children
-
-  $ dbt run --models tag:nightly+       # select "nightly" models and all children
-  $ dbt run --models +tag:nightly+      # select "nightly" models and all parents and children
-
-  $ dbt run --models @source:snowplow   # build all models that select from snowplow sources, plus their parents
-
-  $ dbt test --models config.incremental_strategy:insert_overwrite,test_name:unique   # execute all `unique` tests that select from models using the `insert_overwrite` incremental strategy
-  ```
-
-</VersionBlock>
 
 This can get complex! Let's say I want a nightly run of models that build off snowplow data
 and feed exports, while _excluding_ the biggest incremental models (and one other model, to boot).
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt run --select @source:snowplow,tag:nightly models/export --exclude package:snowplow,config.materialized:incremental export_performance_timing
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt run --models @source:snowplow,tag:nightly models/export --exclude package:snowplow,config.materialized:incremental export_performance_timing
-  ```
-
-</VersionBlock>
 
 This command selects all models that:
 * Select from snowplow sources, plus their parents, _and_ are tagged "nightly"
diff --git a/website/docs/reference/node-selection/set-operators.md b/website/docs/reference/node-selection/set-operators.md
index 605558c0b92..81fe6f21001 100644
--- a/website/docs/reference/node-selection/set-operators.md
+++ b/website/docs/reference/node-selection/set-operators.md
@@ -9,74 +9,35 @@ included in the final set.
 
 Run snowplow_sessions, all ancestors of snowplow_sessions, fct_orders, and all ancestors of fct_orders:
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt run --select +snowplow_sessions +fct_orders
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt run --models +snowplow_sessions +fct_orders
-  ```
-
-</VersionBlock>
-
 ### Intersections
-<Changelog>New in v0.18.0</Changelog>
 
 If multiple arguments to `--select`, `--exclude`, and `--select` can be comma-separated (with no whitespace in between),
 dbt will select only resources which satisfy _all_ arguments.
 
 Run all the common ancestors of snowplow_sessions and fct_orders:
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt run --select +snowplow_sessions,+fct_orders
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt run --models +snowplow_sessions,+fct_orders
-  ```
-
-</VersionBlock>
 
 Run all the common descendents of stg_invoices and stg_accounts:
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt run --select stg_invoices+,stg_accounts+
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt run --models stg_invoices+,stg_accounts+
-  ```
-
-</VersionBlock>
 
 Run models that are in the marts/finance subdirectory *and* tagged nightly:
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt run --select marts.finance,tag:nightly
   ```
-
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt run --models marts.finance,tag:nightly
-  ```
-
-</VersionBlock>
diff --git a/website/docs/reference/node-selection/state-comparison-caveats.md b/website/docs/reference/node-selection/state-comparison-caveats.md
index 79b66598f41..170ec759fb1 100644
--- a/website/docs/reference/node-selection/state-comparison-caveats.md
+++ b/website/docs/reference/node-selection/state-comparison-caveats.md
@@ -12,11 +12,7 @@ If a seed file is >1 MB in size, dbt cannot compare its contents and will raise
 
 ### Macros
 
-<Changelog>
-
-- New in v0.21.0: dbt will mark modified any resource that depends on a changed macro, or on a macro that depends on a changed macro.
-
-</Changelog>
+dbt will mark modified any resource that depends on a changed macro, or on a macro that depends on a changed macro.
 
 ### Vars
 
diff --git a/website/docs/reference/node-selection/syntax.md b/website/docs/reference/node-selection/syntax.md
index 5787ca3355b..57294cbe3f9 100644
--- a/website/docs/reference/node-selection/syntax.md
+++ b/website/docs/reference/node-selection/syntax.md
@@ -24,10 +24,6 @@ We use the terms <a href="https://en.wikipedia.org/wiki/Vertex_(graph_theory)">"
 
 By default, `dbt run` executes _all_ of the models in the dependency graph; `dbt seed` creates all seeds, `dbt snapshot` performs every snapshot. The `--select` flag is used to specify a subset of nodes to execute.
 
-:::info
-Before dbt v0.21, certain commands (notably `run`, `test`, and `compile`) used a flag called `--models` instead of `--select`. The two were functionally identical. Those commands still support the `--models` flag for backwards compatibility.
-:::
-
 ### How does selection work?
 
 1. dbt gathers all the resources that are matched by one or more of the `--select` criteria, in the order of selection methods (e.g. `tag:`), then graph operators (e.g. `+`), then finally set operators (unions, intersections, exclusions).
@@ -53,7 +49,6 @@ The `--select` flag accepts one or more arguments. Each argument can be one of:
 
 Examples:
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt run --select my_dbt_project_name   # runs all models in your project
@@ -65,24 +60,8 @@ Examples:
   $ dbt run --select path/to/my_model.sql  # run a specific model by its path
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt run --models my_dbt_project_name   # runs all models in your project
-  $ dbt run --models my_dbt_model          # runs a specific model
-  $ dbt run --models path.to.my.models     # runs all models in a specific directory
-  $ dbt run --models my_package.some_model # run a specific model in a specific package
-  $ dbt run --models tag:nightly           # run models with the "nightly" tag
-  $ dbt run --models path/to/models        # run models contained in path/to/models
-  $ dbt run --models path/to/my_model.sql  # run a specific model by its path
-  ```
-
-</VersionBlock>
-
 dbt supports a shorthand language for defining subsets of nodes. This language uses the characters `+`, `@`, `*`, and `,`.
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   # multiple arguments can be provided to --select
@@ -95,22 +74,6 @@ dbt supports a shorthand language for defining subsets of nodes. This language u
   $ dbt run --select path:marts/finance,tag:nightly,config.materialized:table
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  # multiple arguments can be provided to --select
-  $ dbt run --models my_first_model my_second_model
-
-  # these arguments can be projects, models, directory paths, tags, or sources
-  $ dbt run --models tag:nightly my_model finance.base.*
-
-  # use methods and intersections for more complex selectors
-  $ dbt run --models path:marts/finance,tag:nightly,config.materialized:table
-  ```
-
-</VersionBlock>
-
 As your selection logic gets more complex, and becomes unwieldly to type out as command-line arguments,
 consider using a [yaml selector](yaml-selectors). You can use a predefined definition with the `--selector` flag.
 Note that when you're using `--selector`, most other flags (namely `--select` and `--exclude`) will be ignored.
diff --git a/website/docs/reference/node-selection/test-selection-examples.md b/website/docs/reference/node-selection/test-selection-examples.md
index fcb4ecd8ccc..fe7025170e7 100644
--- a/website/docs/reference/node-selection/test-selection-examples.md
+++ b/website/docs/reference/node-selection/test-selection-examples.md
@@ -13,9 +13,7 @@ Unlike other resource types, tests can also be selected **indirectly**. If a sel
 
 <Changelog>
 
-* `v0.20.0`: Test selection is no longer greedy for indirect inclusion (ALL parents must be selected for the test to be selected). It is still greedy for indirect exclusion (if ANY parent is excluded, the test is excluded).
-* `v0.21.0`: Introduce `--greedy` flag (and `greedy` selector property), to optionally include tests that are indirectly selected and have an unselected parent.
-* `v1.0.0`: Renamed the `--greedy` flag/property to `indirect_selection`, and set its default back to "eager" (pre-v0.20). You can achieve the "cautious" behavior introduced in v0.20 by setting the flag/property to `cautious`.
+ `v1.0.0`: Renamed the `--greedy` flag/property to `indirect_selection`, and set its default back to "eager" (pre-v0.20). You can achieve the "cautious" behavior introduced in v0.20 by setting the flag/property to `cautious`.
 
 </Changelog>
 
@@ -25,66 +23,34 @@ Test selection is powerful, and we know it can be tricky. To that end, we've inc
 
 <Changelog>
 
-* `v0.18.0`: Introduced the `test_type` selection method. In previous versions, similar behavior is possible via the `--schema` or `--data` flags.
-- `v1.0.0`: Renamed test types: "generic" (formerly "schema") and "singular" (formerly "data"). Removed support for the `--schema` and `--data` flags.
+`v1.0.0`: Renamed test types: "generic" (formerly "schema") and "singular" (formerly "data"). Removed support for the `--schema` and `--data` flags.
 
 </Changelog>
 
 Run generic tests only:
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt test --select test_type:generic
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt test --models test_type:data
-  ```
-
-</VersionBlock>
-
 Run singular tests only:
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt test --select test_type:singular
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt test --models test_type:data
-  ```
-
-</VersionBlock>
-
 In both cases, `test_type` checks a property of the test itself. These are forms of "direct" test selection.
 
 ### Indirect selection
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt test --select customers
   $ dbt test --select orders
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt test --models customers
-  $ dbt test --models orders
-  ```
-
-</VersionBlock>
-
 These are examples of "indirect" selection: `customers` and `orders` select models (whether by name or path). Any tests defined on either `customers` or `orders` will be selected indirectly, and thereby included.
 
  By default, a test will run when ANY parent is selected; we call this "eager" indirect selection. In this example, that would include _any_ test that touches either `customers` or `orders`, even if it touches other models as well.
@@ -99,26 +65,14 @@ Imagine a `relationships` test between `customers` and `orders`. By default, the
 $ dbt test --select customers orders --indirect-selection=cautious
 ```
 
-<VersionBlock firstVersion="0.21">
-
   ```bash
   $ dbt test --select customers orders
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt test --models customers orders
-  ```
-
-</VersionBlock>
-
- ### Syntax examples
+### Syntax examples
 
 The following examples should feel somewhat familiar if you're used to executing `dbt run` with the `--select` option to build parts of your DAG:
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   # Run tests on a model (indirect selection)
@@ -141,35 +95,8 @@ The following examples should feel somewhat familiar if you're used to executing
 
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  # Run tests on a model (indirect selection)
-  $ dbt test --models customers
-
-  # Run tests on all models in the models/staging/jaffle_shop directory (indirect selection)
-  $ dbt test --models staging.jaffle_shop
-
-  # Run tests downstream of a model (note this will select those tests directly!)
-  $ dbt test --models stg_customers+
-
-  # Run tests upstream of a model (indirect selection)
-  $ dbt test --models +stg_customers
-
-  # Run tests on all models with a particular tag (direct + indirect)
-  $ dbt test --models tag:my_model_tag
-
-  # Run tests on all models with a particular materialization (indirect selection)
-  $ dbt test --models config.materialized:table
-
-  ```
-
-</VersionBlock>
-
  The same principle can be extended to tests defined on other resource types. In these cases, we will execute all tests defined on certain sources via the `source:` selection method:
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   # tests on all sources
@@ -185,30 +112,10 @@ The following examples should feel somewhat familiar if you're used to executing
   $ dbt test --exclude source:*
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  # tests on all sources
-  $ dbt test --models source:*
-
-  # tests on one source
-  $ dbt test --models source:jaffle_shop
-
-  # tests on one source table
-  $ dbt test --models source:jaffle_shop.customers
-
-  # tests on everything _except_ sources
-  $ dbt test --exclude source:*
-  ```
-
-</VersionBlock>
-
  ### More complex selection
 
 Through the combination of direct and indirect selection, there are many ways to accomplish the same outcome. Let's say we have a data test named `assert_total_payment_amount_is_positive` that depends on a model named `payments`. All of the following would manage to select and execute that test specifically:
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt test --select assert_total_payment_amount_is_positive # directly select the test by name
@@ -216,20 +123,9 @@ Through the combination of direct and indirect selection, there are many ways to
   $ dbt test --select payments --data  # indirect selection, earlier versions
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt test --models assert_total_payment_amount_is_positive # directly select the test by name
-  $ dbt test --models payments,test_type:data # indirect selection, v0.18.0
-  $ dbt test --models payments --data  # indirect selection, earlier versions
-  ```
-
-</VersionBlock>
 
  As long as you can select a common property of a group of resources, indirect selection allows you to execute all the tests on those resources, too. In the example above, we saw it was possible to test all table-materialized models. This principle can be extended to other resource types, too:
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   # Run tests on all models with a particular materialization
@@ -242,22 +138,6 @@ Through the combination of direct and indirect selection, there are many ways to
   $ dbt test --select config.materialized:snapshot
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  # Run tests on all models with a particular materialization
-  $ dbt test --models config.materialized:table
-
-  # Run tests on all seeds, which use the 'seed' materialization
-  $ dbt test --models config.materialized:seed
-
-  # Run tests on all snapshots, which use the 'snapshot' materialization
-  $ dbt test --models config.materialized:snapshot
-  ```
-
-</VersionBlock>
-
  Note that this functionality may change in future versions of dbt.
 
 ### Run tests on tagged columns
@@ -281,21 +161,11 @@ models:
 
 </File>
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt test --select tag:my_column_tag
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt test --models tag:my_column_tag
-  ```
-
-</VersionBlock>
-
 Currently, tests "inherit" tags applied to columns, sources, and source tables. They do _not_ inherit tags applied to models, seeds, or snapshots. In all likelihood, those tests would still be selected indirectly, because the tag selects its parent. This is a subtle distinction, and it may change in future versions of dbt.
 
 ### Run tagged tests only
@@ -319,17 +189,7 @@ models:
 
 </File>
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt test --select tag:my_test_tag
   ```
-
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt test --models tag:my_test_tag
-  ```
-
-</VersionBlock>
diff --git a/website/docs/reference/node-selection/yaml-selectors.md b/website/docs/reference/node-selection/yaml-selectors.md
index d3527729369..5bd53ac01fe 100644
--- a/website/docs/reference/node-selection/yaml-selectors.md
+++ b/website/docs/reference/node-selection/yaml-selectors.md
@@ -2,14 +2,6 @@
 title: "YAML Selectors"
 ---
 
-<Changelog>
-
-- **v0.18.0**: Introduced YAML selectors
-- **v0.19.0**: Added optional `description` property. Selectors appear in `manifest.json` under a new `selectors` key.
-- **v0.21.0**: Added optional `default` + `greedy` properties
-
-</Changelog>
-
 Write resource selectors in YAML, save them with a human-friendly name, and reference them using the `--selector` flag.
 By recording selectors in a top-level `selectors.yml` file:
 
@@ -139,21 +131,11 @@ See [test selection examples](test-selection-examples) for more details about in
 
 Here are two ways to represent:
 
-<VersionBlock firstVersion="0.21">
 
   ```bash
   $ dbt run --select @source:snowplow,tag:nightly models/export --exclude package:snowplow,config.materialized:incremental export_performance_timing
   ```
 
-</VersionBlock>
-<VersionBlock lastVersion="0.20">
-
-  ```bash
-  $ dbt run --models @source:snowplow,tag:nightly models/export --exclude package:snowplow,config.materialized:incremental export_performance_timing
-  ```
-
-</VersionBlock>
-
 <Tabs
   defaultValue="cli_style"
   values={[
@@ -222,7 +204,7 @@ $ dbt run --selector nightly_diet_snowplow
 
 ## Default
 
-Starting in v0.21, selectors may define a boolean `default` property. If a selector has `default: true`, dbt will use this selector's criteria when tasks do not define their own selection criteria.
+Selectors may define a boolean `default` property. If a selector has `default: true`, dbt will use this selector's criteria when tasks do not define their own selection criteria.
 
 Let's say we define a default selector that only selects resources defined in our root project:
 ```yml
diff --git a/website/docs/reference/project-configs/dispatch-config.md b/website/docs/reference/project-configs/dispatch-config.md
index 6cb8060949c..5c4e286c1f5 100644
--- a/website/docs/reference/project-configs/dispatch-config.md
+++ b/website/docs/reference/project-configs/dispatch-config.md
@@ -37,7 +37,7 @@ dispatch:
 
 I've reimplemented certain macros from the `dbt_utils` package in my root project (`'my_root_project'`), and I want my versions to take precedence. Otherwise, fall back to the versions in `dbt_utils`.
 
-_Note: As of v0.21.1, this is the default behavior. You may optionally choose to express that search order explicitly as:_
+_Note: This is the default behavior. You may optionally choose to express that search order explicitly as:_
 
 <File name='dbt_project.yml'>
 
diff --git a/website/docs/reference/resource-configs/column_types.md b/website/docs/reference/resource-configs/column_types.md
index 274166a9aba..8d236171ba2 100644
--- a/website/docs/reference/resource-configs/column_types.md
+++ b/website/docs/reference/resource-configs/column_types.md
@@ -26,7 +26,7 @@ seeds:
 
 
 
-Or (as of v0.21):
+Or:
 
 <File name='seeds/properties.yml'>
 
diff --git a/website/docs/reference/resource-configs/fail_calc.md b/website/docs/reference/resource-configs/fail_calc.md
index 8f3c0fe0c1a..6ee8e5f71ce 100644
--- a/website/docs/reference/resource-configs/fail_calc.md
+++ b/website/docs/reference/resource-configs/fail_calc.md
@@ -3,13 +3,6 @@ resource_types: [tests]
 datatype: string
 ---
 
-<Changelog>
-
-* `v0.20.0`: Introduced `fail_calc` config
-* `v0.21.0`: Introduced `config` property for tests
-
-</Changelog>
-
 Test queries are written to return a set of failing records, ones not matching the expectation or assertion declared by that test: duplicate records, null values, etc.
 
 Most often, this is the count of rows returned by the test query: the default value of `fail_calc` is `count(*)`. But it can also be a custom calculation, whether an aggregate calculation or simply the name of a column to be selected from the test query.
diff --git a/website/docs/reference/resource-configs/limit.md b/website/docs/reference/resource-configs/limit.md
index 348d93bb720..535bf905bb2 100644
--- a/website/docs/reference/resource-configs/limit.md
+++ b/website/docs/reference/resource-configs/limit.md
@@ -3,13 +3,6 @@ resource_types: [tests]
 datatype: integer
 ---
 
-<Changelog>
-
-* `v0.20.0`: Introduced `limit` config
-* `v0.21.0`: Introduced `config` property for tests
-
-</Changelog>
-
 Limit the number of failures that will be returned by a test query. We recommend using this config when working with large datasets and [storing failures in the database](store_failures).
 
 <Tabs
diff --git a/website/docs/reference/resource-configs/meta.md b/website/docs/reference/resource-configs/meta.md
index 948982925b0..c3cf78161e8 100644
--- a/website/docs/reference/resource-configs/meta.md
+++ b/website/docs/reference/resource-configs/meta.md
@@ -178,12 +178,6 @@ The `meta` field can be used to set metadata for a resource. This metadata is co
 
 Depending on the resource you're configuring, `meta` may be available within the `config` property, or as a top-level key. (For backwards compatibility, `meta` is always supported as a top-level key, though without the capabilities of config inheritance.)
 
-<Changelog>
-
-* `v0.16.0`: This property was introduced
-* `v0.21.0`: Introduced the `config` property, and gave `meta` the capabilities of a config
-
-</Changelog>
 
 ## Examples
 ### Designate a model owner
diff --git a/website/docs/reference/resource-configs/persist_docs.md b/website/docs/reference/resource-configs/persist_docs.md
index 9dec5b6cefe..ea384e37cb8 100644
--- a/website/docs/reference/resource-configs/persist_docs.md
+++ b/website/docs/reference/resource-configs/persist_docs.md
@@ -154,12 +154,6 @@ Some known issues and limitations:
 
 </VersionBlock>
 
-<VersionBlock lastVersion="0.21">
-
-- Column-level comments aren't supported for models materialized as <Term id="view">views</Term>
-
-</VersionBlock>
-
 </div>
 
 </WHCode>
diff --git a/website/docs/reference/resource-configs/quote_columns.md b/website/docs/reference/resource-configs/quote_columns.md
index 5701fe0f11f..f70b18cc75d 100644
--- a/website/docs/reference/resource-configs/quote_columns.md
+++ b/website/docs/reference/resource-configs/quote_columns.md
@@ -12,8 +12,6 @@ An optional seed configuration, used to determine whether column names in the se
 
 <Changelog>
 
-* `v0.15.0`: Introduced in v0.15.0, with a default of False
-* `v0.21.0`: Introduced `config` property for seeds
 * Future: The default value may change in a future release. If you're using seed files, it is recommended that you set this configuration explicitly to avoid breaking changes in the future.
 
 </Changelog>
diff --git a/website/docs/reference/seed-configs.md b/website/docs/reference/seed-configs.md
index b7da013a133..2bfdbb2f208 100644
--- a/website/docs/reference/seed-configs.md
+++ b/website/docs/reference/seed-configs.md
@@ -2,11 +2,6 @@
 title: Seed configurations
 ---
 
-<Changelog>
-    - **v0.21.0** introduced the `config` property, thereby allowing you to configure seeds in all `.yml` files
-</Changelog>
-
-
 ## Available configurations
 ### Seed-specific configurations
 
diff --git a/website/docs/reference/seed-properties.md b/website/docs/reference/seed-properties.md
index 7fbed82dc27..3c949eddadb 100644
--- a/website/docs/reference/seed-properties.md
+++ b/website/docs/reference/seed-properties.md
@@ -3,8 +3,9 @@ title: Seed properties
 ---
 
 <Changelog>
-    - **v0.21.0** introduced the `config` property, thereby allowing you to configure seeds in all `.yml` files
-    - **v1.0.0:** The default path for [`seed-paths`](seed-paths) (formerly `data-paths`) is now `seeds`.
+  
+  **v1.0.0:** The default path for [`seed-paths`](seed-paths) (formerly `data-paths`) is now `seeds`.
+  
 </Changelog>
 
 Seed properties can be declared in `.yml` files under a `seed` key.
diff --git a/website/docs/reference/snapshot-properties.md b/website/docs/reference/snapshot-properties.md
index c4fa4cac218..49e491d9758 100644
--- a/website/docs/reference/snapshot-properties.md
+++ b/website/docs/reference/snapshot-properties.md
@@ -2,10 +2,6 @@
 title: Snapshot properties
 ---
 
-<Changelog>
-    - **v0.21.0** introduced the `config` property, thereby allowing you to configure snapshots in all `.yml` files
-</Changelog>
-
 Snapshots properties can be declared in `.yml` files in:
 - your `snapshots/` directory (as defined by the [`snapshot-paths` config](snapshot-paths))
 - your `models/` directory (as defined by the [`model-paths` config](model-paths))
diff --git a/website/docs/reference/test-configs.md b/website/docs/reference/test-configs.md
index 88255e62189..0a488ced568 100644
--- a/website/docs/reference/test-configs.md
+++ b/website/docs/reference/test-configs.md
@@ -6,14 +6,6 @@ title: Test configurations
 
 * [Tests](/docs/build/tests)
 
-<Changelog>
-
-* `v0.20.0`: Introduced the ability to configure tests from `dbt_project.yml`, and to configure `enabled` for generic tests. Introduced `fail_calc`, `where`, `error_if`, `warn_if`, `store_failures`, and `where` configs.
-* `v0.21.0`: Introduced the `config()` dictionary, making it easier and clearer to configure specific instances of generic tests
-
-
-</Changelog>
-
 Tests can be configured in a few different ways:
 1. Properties within `.yml` definition (generic tests only, see [test properties](resource-properties/tests) for full syntax)
 2. A `config()` block within the test's SQL definition
diff --git a/website/snippets/core-versions-table.md b/website/snippets/core-versions-table.md
index 7ecf61e5b96..024541acf48 100644
--- a/website/snippets/core-versions-table.md
+++ b/website/snippets/core-versions-table.md
@@ -1,10 +1,9 @@
 | dbt Core                        | Initial Release | Active Support Until | Critical Support Until  | dbt Cloud Until | Final Patch |
 |---------------------------------|-----------------|----------------------|-------------------------|-----------------|-------------|
-| **v0.X**                        | (various dates) | v1.0.0 release       | Dec 3, 2021             | See below ⚠️     | v0.21.1     |
 | [**v1.0**](upgrading-to-v1.0)   | Dec 3, 2021     | v1.1.0 release       | Dec 3, 2022             | Dec 2022        |             |
 | [**v1.1**](upgrading-to-v1.1)   | Apr 28, 2022    | v1.2.0 release       | Apr 28, 2023            | Apr 2023        |             |
 | [**v1.2**](upgrading-to-v1.2)   | Jul 26, 2022    | v1.3.0 release       | Jul 26, 2023            | Jul 2023        |             |
 | [**v1.3**](upgrading-to-v1.3)   | Oct 12, 2022    | v1.4.0 release       | Oct 12, 2023            | Oct 2023        |             |
 | _**v1.4**_                      | _Jan 2023_      | _v1.5.0 release_     | _Jan 2024_              | _Jan 2024_      |             |
 
-_Italics: Future releases, NOT definite commitments. Shown for indication only._
+_Future release dates are tentative and subject to change._

From b3fe09d5321d6dc24b73b365131e93bb1a9f9b32 Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Wed, 7 Dec 2022 13:45:02 -0500
Subject: [PATCH 02/19] Update website/docs/docs/dbt-versions/core-versions.md

---
 website/docs/docs/dbt-versions/core-versions.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/docs/docs/dbt-versions/core-versions.md b/website/docs/docs/dbt-versions/core-versions.md
index e1a0f68f0c6..e3875e3eadf 100644
--- a/website/docs/docs/dbt-versions/core-versions.md
+++ b/website/docs/docs/dbt-versions/core-versions.md
@@ -22,7 +22,7 @@ All dbt Core versions released prior to 1.0 and their version-specific documenta
 
 ### Minor versions
 
-Minor versions include new features and capabilities. They will be supported for one year from the date of their initial release. _dbt Labs is committed to this 12 month support window._ Our mechanism for continuing to support a minor version is by releasing new patches: small, targeted bug fixes. Whenever we refer to a minor version, such as v1.0, we always mean its latest available patch release (v1.0.x).
+Minor versions include new features and capabilities. They will be supported for one year from their initial release date. _dbt Labs is committed to this 12-month support timeframe._ Our mechanism for continuing to support a minor version is by releasing new patches: small, targeted bug fixes. Whenever we refer to a minor version, such as v1.0, we always mean its latest available patch release (v1.0.x).
 
 While a minor version is officially supported:
 - You can use it in dbt Cloud. For more on dbt Cloud versioning, see [Choosing a dbt version](cloud-choosing-a-dbt-version).

From ee49e34b773a3aef0dacb9ff72c7168529ce4d7e Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Wed, 7 Dec 2022 13:45:58 -0500
Subject: [PATCH 03/19] Update website/docs/docs/dbt-versions/core-versions.md

---
 website/docs/docs/dbt-versions/core-versions.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/docs/docs/dbt-versions/core-versions.md b/website/docs/docs/dbt-versions/core-versions.md
index e3875e3eadf..3663aafe00d 100644
--- a/website/docs/docs/dbt-versions/core-versions.md
+++ b/website/docs/docs/dbt-versions/core-versions.md
@@ -30,7 +30,7 @@ While a minor version is officially supported:
 
 ### Ongoing patches
 
-During the 12 month support window, we will continue to release new patch versions that include fixes.
+During the 12-month support window, we will continue to release new patch versions that include fixes.
 
 **Active Support:** In the first few months after a minor version's initial release, we will patch it with "bugfix" releases. These will include fixes for regressions and net-new bugs that were present in the minor version's original release.
 

From 1404f09c7da0360f5587cde7af33bb2f588d3209 Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Wed, 7 Dec 2022 13:47:03 -0500
Subject: [PATCH 04/19] Update website/docs/docs/dbt-versions/core-versions.md

---
 website/docs/docs/dbt-versions/core-versions.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/docs/docs/dbt-versions/core-versions.md b/website/docs/docs/dbt-versions/core-versions.md
index 3663aafe00d..fc6904555a2 100644
--- a/website/docs/docs/dbt-versions/core-versions.md
+++ b/website/docs/docs/dbt-versions/core-versions.md
@@ -52,7 +52,7 @@ We expect users to upgrade to patches as soon as they're available. When we refe
 
 ### Upgrading to new minor versions
 
-During the official support window period, minor versions will remain available in dbt Cloud, and in the version dropdown on the docs site. While we do not expect users to immediately upgrade to newer minor versions as soon as they're available, there will always be some features and fixes that are only available for users of the latest minor version.
+During the official support period, minor versions will remain available in dbt Cloud and the version dropdown on the docs site. While we do not expect users to immediately upgrade to newer minor versions as soon as they're available, there will always be some features and fixes only available for users of the latest minor version.
 
 ### Trying prereleases
 

From 86d04da3b12f68f6242370eecc6708ed2ef8e38d Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Wed, 7 Dec 2022 13:59:27 -0500
Subject: [PATCH 05/19] Delete understanding-state.md

---
 .../docs/guides/legacy/understanding-state.md | 101 ------------------
 1 file changed, 101 deletions(-)
 delete mode 100644 website/docs/guides/legacy/understanding-state.md

diff --git a/website/docs/guides/legacy/understanding-state.md b/website/docs/guides/legacy/understanding-state.md
deleted file mode 100644
index 7ed88f586e6..00000000000
--- a/website/docs/guides/legacy/understanding-state.md
+++ /dev/null
@@ -1,101 +0,0 @@
----
-title: "Understanding state"
----
-
-<Changelog>
-
- - The `--state` flag was introduced in dbt v0.18.0
- - The `result` selector was introduced in dbt v1.0.0
-
-</Changelog>
-
-One of the greatest underlying assumptions about dbt is that its operations should be **stateless** and **<Term id="idempotent" />**. That is, it doesn't matter how many times a model has been run before, or if it has ever been run before. It doesn't matter if you run it once or a thousand times. Given the same raw data, you can expect the same transformed result. A given run of dbt doesn't need to "know" about _any other_ run; it just needs to know about the code in the project and the objects in your database as they exist _right now_.
-
-That said, dbt does store "state"—a detailed, point-in-time view of project resources, database objects, and invocation results—in the form of its [artifacts](dbt-artifacts). If you choose, dbt can use these artifacts to inform certain  operations. Crucially, the operations themselves are still stateless and <Term id="idempotent" />: given the same manifest and the same raw data, dbt will produce the same transformed result.
-
-dbt can leverage artifacts from a prior invocation as long as their file path is passed to the `--state` flag. This is a prerequisite for:
-- [The `state:` selector](methods#the-state-method), whereby dbt can identify resources that are new or modified
-by comparing code in the current project against the state manifest.
-- [Deferring](defer) to another environment, whereby dbt can identify upstream, unselected resources that don't exist in your current environment and instead "defer" their references to the environment provided by the state manifest.
-
-Together, these two features enable ["slim CI"](best-practices#run-only-modified-models-to-test-changes-slim-ci). We expect to add more features in future releases that can leverage artifacts passed to the `--state` flag.
-
-### Establishing state
-
-State and defer can be set by environment variables as well as CLI flags:
-
-- `--state` or `DBT_ARTIFACT_STATE_PATH`: file path
-- `--defer` or `DBT_DEFER_TO_STATE`: boolean
-
-If both the flag and env var are provided, the flag takes precedence.
-
-#### Notes:
-- The `--state` artifacts must be of schema versions that are compatible with the currently running dbt version.
-- The path to state artifacts can be set via the `--state` flag or `DBT_ARTIFACT_STATE_PATH` environment variable. If both the flag and env var are provided, the flag takes precedence.
-- These are powerful, complex features. Read about [known caveats and limitations](node-selection/state-comparison-caveats) to state comparison.
-
-### The "result" status
-
-Another element of job state is the `result` of a prior dbt invocation. After executing a `dbt run`, for example, dbt creates the `run_results.json` artifact which contains execution times and success / error status for dbt models. You can read more about `run_results.json` on the ['run results'](/docs/reference/artifacts/run-results-json) page. 
-
-The following dbt commands produce `run_results.json` artifacts whose results can be referenced in subsequent dbt invocations:  
-- `dbt run`
-- `dbt test`
-- `dbt build`
-- `dbt seed` 
-
-After issuing one of the above commands, you can reference the results by adding a selector to a subsequent command as follows: 
-
-```bash
-# You can also set the DBT_ARTIFACT_STATE_PATH environment variable instead of the --state flag.
-$ dbt run --select result:<status> --defer --state path/to/prod/artifacts
-```
-
-The available options depend on the node type: 
-
-|                | model | seed | snapshot | test |
-|----------------|-------|------|------|----------|
-| `result:error`   | ✅    | ✅    | ✅    |  ✅      |
-| `result:success` | ✅    | ✅    | ✅     |         |
-| `result:skipped` | ✅    |      |  ✅    | ✅       |
-| `result:fail`    |       |      |     |   ✅       |
-| `result:warn`    |       |      |      |  ✅        |
-| `result:pass`    |       |      |      |  ✅      |
-
-### Combining `state` and `result` selectors
-
-The state and result selectors can also be combined in a single invocation of dbt to capture errors from a previous run AND any new or modified models.
-
-```bash
-$ dbt run --select result:<status>+ state:modified+ --defer --state ./<dbt-artifact-path>
-```
-
-### The "source_status" status
-<VersionBlock lastVersion="1.0">
-
-Only supported by v1.1 or newer.
-
-</VersionBlock>
-
-<VersionBlock firstVersion="1.1">
-
-Only supported by v1.1 or newer.
-
-:::caution Experimental functionality
-The `source_status` selection method is experimental and subject to change. During this time, ongoing improvements may limit this feature’s availability and cause breaking changes to its functionality.
-:::
-
-
-Another element of job state is the `source_status` of a prior dbt invocation. After executing `dbt source freshness`, for example, dbt creates the `sources.json` artifact which contains execution times and `max_loaded_at` dates for dbt sources. You can read more about `sources.json` on the ['sources'](/docs/reference/artifacts/sources-json) page. 
-
-The following dbt commands produce `sources.json` artifacts whose results can be referenced in subsequent dbt invocations:  
-- `dbt source freshness`
-
-After issuing one of the above commands, you can reference the source freshness results by adding a selector to a subsequent command as follows: 
-
-```bash
-# You can also set the DBT_ARTIFACT_STATE_PATH environment variable instead of the --state flag.
-$ dbt source freshness # must be run again to compare current to previous state
-$ dbt build --select source_status:fresher+ --state path/to/prod/artifacts
-```
-</VersionBlock>

From c37f5d4a4b8889fefb3c36ec2fa414510019a431 Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Wed, 7 Dec 2022 15:00:25 -0500
Subject: [PATCH 06/19] Update core-versions-table.md

---
 website/snippets/core-versions-table.md | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/website/snippets/core-versions-table.md b/website/snippets/core-versions-table.md
index 024541acf48..85f430c2053 100644
--- a/website/snippets/core-versions-table.md
+++ b/website/snippets/core-versions-table.md
@@ -1,9 +1,12 @@
-| dbt Core                        | Initial Release | Active Support Until | Critical Support Until  | dbt Cloud Until | Final Patch |
+| dbt Core                        | Initial Release | Active Support Until | Critical Support Until  | dbt Cloud Until | Status      |
 |---------------------------------|-----------------|----------------------|-------------------------|-----------------|-------------|
-| [**v1.0**](upgrading-to-v1.0)   | Dec 3, 2021     | v1.1.0 release       | Dec 3, 2022             | Dec 2022        |             |
-| [**v1.1**](upgrading-to-v1.1)   | Apr 28, 2022    | v1.2.0 release       | Apr 28, 2023            | Apr 2023        |             |
-| [**v1.2**](upgrading-to-v1.2)   | Jul 26, 2022    | v1.3.0 release       | Jul 26, 2023            | Jul 2023        |             |
-| [**v1.3**](upgrading-to-v1.3)   | Oct 12, 2022    | v1.4.0 release       | Oct 12, 2023            | Oct 2023        |             |
-| _**v1.4**_                      | _Jan 2023_      | _v1.5.0 release_     | _Jan 2024_              | _Jan 2024_      |             |
-
+| [**vX.0**]                      | (Various dates) | v1.0 release         | Deprecated              | Deprecated      |  Deprecated |
+| [**v1.0**](upgrading-to-v1.0)   | Dec 3, 2021     | v1.1.0 release       | Dec 3, 2022             | Dec 2022        |  EOL        |
+| [**v1.1**](upgrading-to-v1.1)   | Apr 28, 2022    | v1.2.0 release       | Apr 28, 2023            | Apr 2023        |  GA         |
+| [**v1.2**](upgrading-to-v1.2)   | Jul 26, 2022    | v1.3.0 release       | Jul 26, 2023            | Jul 2023        |  GA         |
+| [**v1.3**](upgrading-to-v1.3)   | Oct 12, 2022    | v1.4.0 release       | Oct 12, 2023            | Oct 2023        |  GA         |
+| _**v1.4**_                      | _Jan 2023_      | _v1.5.0 release_     | _Jan 2024_              | _Jan 2024_      |  TBA        |
+| _**v1.5**_                      | _Apr 2023_      | _v1.6.0 release_     | _Apr 2024_              | _Apr 2024_      |  TBA        |
+| _**v1.6**_                      | _July 2023_     | _v1.7.0 release_     | _July 2024_             | _July 2024_     |  TBA        |
+| _**v1.7**_                      | _Oct 2023_      | _v1.8.0 release_     | _Oct 2024_              | _Oct 2024_      |  TBA        |
 _Future release dates are tentative and subject to change._

From c6ce1c593f04dec82df80964f14d06c8058df739 Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Wed, 7 Dec 2022 15:03:43 -0500
Subject: [PATCH 07/19] Update website/snippets/core-versions-table.md

---
 website/snippets/core-versions-table.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/snippets/core-versions-table.md b/website/snippets/core-versions-table.md
index 85f430c2053..a86af7f9f4a 100644
--- a/website/snippets/core-versions-table.md
+++ b/website/snippets/core-versions-table.md
@@ -1,6 +1,6 @@
 | dbt Core                        | Initial Release | Active Support Until | Critical Support Until  | dbt Cloud Until | Status      |
 |---------------------------------|-----------------|----------------------|-------------------------|-----------------|-------------|
-| [**vX.0**]                      | (Various dates) | v1.0 release         | Deprecated              | Deprecated      |  Deprecated |
+| [**v0.X**]                      | (Various dates) | v1.0 release         | Deprecated              | Deprecated      |  Deprecated |
 | [**v1.0**](upgrading-to-v1.0)   | Dec 3, 2021     | v1.1.0 release       | Dec 3, 2022             | Dec 2022        |  EOL        |
 | [**v1.1**](upgrading-to-v1.1)   | Apr 28, 2022    | v1.2.0 release       | Apr 28, 2023            | Apr 2023        |  GA         |
 | [**v1.2**](upgrading-to-v1.2)   | Jul 26, 2022    | v1.3.0 release       | Jul 26, 2023            | Jul 2023        |  GA         |

From ec706d36c11eed5b00f4bcd382be56af108d8dc4 Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Wed, 7 Dec 2022 17:04:08 -0500
Subject: [PATCH 08/19] Update website/snippets/core-versions-table.md

---
 website/snippets/core-versions-table.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/snippets/core-versions-table.md b/website/snippets/core-versions-table.md
index a86af7f9f4a..4992e8c20d1 100644
--- a/website/snippets/core-versions-table.md
+++ b/website/snippets/core-versions-table.md
@@ -1,6 +1,6 @@
 | dbt Core                        | Initial Release | Active Support Until | Critical Support Until  | dbt Cloud Until | Status      |
 |---------------------------------|-----------------|----------------------|-------------------------|-----------------|-------------|
-| [**v0.X**]                      | (Various dates) | v1.0 release         | Deprecated              | Deprecated      |  Deprecated |
+|  **v0.X**                      | (Various dates) | v1.0 release         | Deprecated              | Deprecated      |  Deprecated |
 | [**v1.0**](upgrading-to-v1.0)   | Dec 3, 2021     | v1.1.0 release       | Dec 3, 2022             | Dec 2022        |  EOL        |
 | [**v1.1**](upgrading-to-v1.1)   | Apr 28, 2022    | v1.2.0 release       | Apr 28, 2023            | Apr 2023        |  GA         |
 | [**v1.2**](upgrading-to-v1.2)   | Jul 26, 2022    | v1.3.0 release       | Jul 26, 2023            | Jul 2023        |  GA         |

From 32fea35e40d08cd2455791eda01e7b54163eef18 Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Tue, 3 Jan 2023 20:31:05 -0500
Subject: [PATCH 09/19] Update dbt-versions.js

---
 website/dbt-versions.js | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/website/dbt-versions.js b/website/dbt-versions.js
index 7000414bdfd..1a780e9290f 100644
--- a/website/dbt-versions.js
+++ b/website/dbt-versions.js
@@ -1,4 +1,8 @@
 exports.versions = [
+  {
+    version: "1.4",
+    EOLDate: "2024-01-25",
+  },
   {
     version: "1.3",
     EOLDate: "2023-10-12",

From 25b329bb1f118c01f3bd28e5d475f47d0fa610e2 Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Tue, 3 Jan 2023 20:35:40 -0500
Subject: [PATCH 10/19] Update core-versions-table.md

---
 website/snippets/core-versions-table.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/snippets/core-versions-table.md b/website/snippets/core-versions-table.md
index 4992e8c20d1..b350321520f 100644
--- a/website/snippets/core-versions-table.md
+++ b/website/snippets/core-versions-table.md
@@ -1,11 +1,11 @@
 | dbt Core                        | Initial Release | Active Support Until | Critical Support Until  | dbt Cloud Until | Status      |
 |---------------------------------|-----------------|----------------------|-------------------------|-----------------|-------------|
-|  **v0.X**                      | (Various dates) | v1.0 release         | Deprecated              | Deprecated      |  Deprecated |
-| [**v1.0**](upgrading-to-v1.0)   | Dec 3, 2021     | v1.1.0 release       | Dec 3, 2022             | Dec 2022        |  EOL        |
-| [**v1.1**](upgrading-to-v1.1)   | Apr 28, 2022    | v1.2.0 release       | Apr 28, 2023            | Apr 2023        |  GA         |
-| [**v1.2**](upgrading-to-v1.2)   | Jul 26, 2022    | v1.3.0 release       | Jul 26, 2023            | Jul 2023        |  GA         |
-| [**v1.3**](upgrading-to-v1.3)   | Oct 12, 2022    | v1.4.0 release       | Oct 12, 2023            | Oct 2023        |  GA         |
-| _**v1.4**_                      | _Jan 2023_      | _v1.5.0 release_     | _Jan 2024_              | _Jan 2024_      |  TBA        |
+|  **v0.X**                       | (Various dates) | v1.0 release         | Deprecated              | Deprecated      |  Deprecated |
+| [**v1.0**](upgrading-to-v1.0)   | Dec 3, 2021     | v1.1.0 release       | Dec 3, 2022             | Dec 2022        |  Deprecated |
+| [**v1.1**](upgrading-to-v1.1)   | Apr 28, 2022    | v1.2.0 release       | Apr 28, 2023            | Apr 2023        |  Released   |
+| [**v1.2**](upgrading-to-v1.2)   | Jul 26, 2022    | v1.3.0 release       | Jul 26, 2023            | Jul 2023        |  Released   |
+| [**v1.3**](upgrading-to-v1.3)   | Oct 12, 2022    | v1.4.0 release       | Oct 12, 2023            | Oct 2023        |  Released   |
+| _**v1.4**_                      | Jan 25, 2023    | v1.5.0 release       | Jan 25, 2024            | Jan 2024        |  Beta       |
 | _**v1.5**_                      | _Apr 2023_      | _v1.6.0 release_     | _Apr 2024_              | _Apr 2024_      |  TBA        |
 | _**v1.6**_                      | _July 2023_     | _v1.7.0 release_     | _July 2024_             | _July 2024_     |  TBA        |
 | _**v1.7**_                      | _Oct 2023_      | _v1.8.0 release_     | _Oct 2024_              | _Oct 2024_      |  TBA        |

From 588e7e7e85274010831c0072313a199b49d88de3 Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Tue, 3 Jan 2023 20:38:29 -0500
Subject: [PATCH 11/19] Update core-versions-table.md

---
 website/snippets/core-versions-table.md | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/snippets/core-versions-table.md b/website/snippets/core-versions-table.md
index b350321520f..558d43a8e08 100644
--- a/website/snippets/core-versions-table.md
+++ b/website/snippets/core-versions-table.md
@@ -1,12 +1,12 @@
-| dbt Core                        | Initial Release | Active Support Until | Critical Support Until  | dbt Cloud Until | Status      |
-|---------------------------------|-----------------|----------------------|-------------------------|-----------------|-------------|
-|  **v0.X**                       | (Various dates) | v1.0 release         | Deprecated              | Deprecated      |  Deprecated |
-| [**v1.0**](upgrading-to-v1.0)   | Dec 3, 2021     | v1.1.0 release       | Dec 3, 2022             | Dec 2022        |  Deprecated |
-| [**v1.1**](upgrading-to-v1.1)   | Apr 28, 2022    | v1.2.0 release       | Apr 28, 2023            | Apr 2023        |  Released   |
-| [**v1.2**](upgrading-to-v1.2)   | Jul 26, 2022    | v1.3.0 release       | Jul 26, 2023            | Jul 2023        |  Released   |
-| [**v1.3**](upgrading-to-v1.3)   | Oct 12, 2022    | v1.4.0 release       | Oct 12, 2023            | Oct 2023        |  Released   |
-| _**v1.4**_                      | Jan 25, 2023    | v1.5.0 release       | Jan 25, 2024            | Jan 2024        |  Beta       |
-| _**v1.5**_                      | _Apr 2023_      | _v1.6.0 release_     | _Apr 2024_              | _Apr 2024_      |  TBA        |
-| _**v1.6**_                      | _July 2023_     | _v1.7.0 release_     | _July 2024_             | _July 2024_     |  TBA        |
-| _**v1.7**_                      | _Oct 2023_      | _v1.8.0 release_     | _Oct 2024_              | _Oct 2024_      |  TBA        |
+| dbt Core                        | Initial Release | Active Support Until | Critical Support Until  | dbt Cloud Until |
+|---------------------------------|-----------------|----------------------|-------------------------|-----------------|
+|  **v0.X**                       | (Various dates) | v1.0 release         | Deprecated              | Deprecated      |
+| [**v1.0**](upgrading-to-v1.0)   | Dec 3, 2021     | v1.1.0 release       | Dec 3, 2022             | Dec 2022        |
+| [**v1.1**](upgrading-to-v1.1)   | Apr 28, 2022    | v1.2.0 release       | Apr 28, 2023            | Apr 2023        |
+| [**v1.2**](upgrading-to-v1.2)   | Jul 26, 2022    | v1.3.0 release       | Jul 26, 2023            | Jul 2023        |
+| [**v1.3**](upgrading-to-v1.3)   | Oct 12, 2022    | v1.4.0 release       | Oct 12, 2023            | Oct 2023        |
+| _**v1.4**_                      | Jan 25, 2023    | v1.5.0 release       | Jan 25, 2024            | Jan 2024        |
+| _**v1.5**_                      | _Apr 2023_      | _v1.6.0 release_     | _Apr 2024_              | _Apr 2024_      |
+| _**v1.6**_                      | _July 2023_     | _v1.7.0 release_     | _July 2024_             | _July 2024_     |
+| _**v1.7**_                      | _Oct 2023_      | _v1.8.0 release_     | _Oct 2024_              | _Oct 2024_      |
 _Future release dates are tentative and subject to change._

From a492cb6d482741562b3c69bba53f65703ae1347d Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Mon, 9 Jan 2023 20:49:57 -0500
Subject: [PATCH 12/19] Update dbt-versions.js

---
 website/dbt-versions.js | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/dbt-versions.js b/website/dbt-versions.js
index 1a780e9290f..a5a4182a49d 100644
--- a/website/dbt-versions.js
+++ b/website/dbt-versions.js
@@ -50,4 +50,6 @@ exports.versionedPages = [
     "page": "reference/dbt-jinja-functions/print",
     "firstVersion": "1.1",
   }
+    "Page": "reference/dbt-jinja-functions/local-md5",
+    "firstVersion": "1.4",
 ]

From 58d87267d484c60da206732ac2695f22eb902b90 Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Mon, 9 Jan 2023 20:55:10 -0500
Subject: [PATCH 13/19] Update website/dbt-versions.js

---
 website/dbt-versions.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/dbt-versions.js b/website/dbt-versions.js
index a5a4182a49d..8f755154434 100644
--- a/website/dbt-versions.js
+++ b/website/dbt-versions.js
@@ -50,6 +50,6 @@ exports.versionedPages = [
     "page": "reference/dbt-jinja-functions/print",
     "firstVersion": "1.1",
   }
-    "Page": "reference/dbt-jinja-functions/local-md5",
+    "page": "reference/dbt-jinja-functions/local-md5",
     "firstVersion": "1.4",
 ]

From 35a362cb6a5734a6d2489765d977c7b632513015 Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Mon, 9 Jan 2023 20:58:36 -0500
Subject: [PATCH 14/19] Update website/docs/docs/dbt-versions/core-versions.md

Co-authored-by: Jeremy Cohen <jeremy@dbtlabs.com>
---
 website/docs/docs/dbt-versions/core-versions.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/docs/docs/dbt-versions/core-versions.md b/website/docs/docs/dbt-versions/core-versions.md
index fc6904555a2..7e99c56663d 100644
--- a/website/docs/docs/dbt-versions/core-versions.md
+++ b/website/docs/docs/dbt-versions/core-versions.md
@@ -62,7 +62,7 @@ All dbt Core versions are available as _prereleases_ before the final release. "
 
 Like many software projects, dbt Core releases follow [semantic versioning](https://semver.org/), which defines three types of version releases.
 
-- **Major versions:** To date, dbt Core has had one major version release: v1.0.0. When v2.0.0 is released, it will introduce new features and backwards compatibility for functionality that has been deprecated will no longer work.
+- **Major versions:** To date, dbt Core has had one major version release: v1.0.0. When v2.0.0 is released, it will introduce new features, and functionality that has been announced for deprecation will stop working.
 - **Minor versions**, also called "feature" releases, include a mix of new features, behind-the-scenes improvements, and changes to existing capabilities that are **backwards compatible** with previous minor versions. They will not break code in your project that relies on documented functionality.
 - **Patch versions**, also called "bugfix" or "security" releases, include **fixes _only_**. These fixes could be needed to restore previous (documented) behavior, fix obvious shortcomings of new features, or offer critical fixes for security or installation issues. We are judicious about which fixes are included in patch releases, to minimize the surface area of changes.
 

From 6066e920ab660529fe6c0e6d897eb2fd5e032068 Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Mon, 9 Jan 2023 21:01:57 -0500
Subject: [PATCH 15/19] Update website/docs/faqs/Tests/testing-sources.md

---
 website/docs/faqs/Tests/testing-sources.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/website/docs/faqs/Tests/testing-sources.md b/website/docs/faqs/Tests/testing-sources.md
index fc93ba5518c..8eb769026e5 100644
--- a/website/docs/faqs/Tests/testing-sources.md
+++ b/website/docs/faqs/Tests/testing-sources.md
@@ -26,4 +26,3 @@ And, to run tests on one source <Term id="table" /> only:
 $ dbt test --select source:jaffle_shop.orders
 ```
 
-Yep, we know this syntax is a little less than ideal, so we're hoping to improve it in a future release. Check out the [model selection syntax](node-selection/syntax) for more examples!

From 22492d20a31cc36320e082b949581aaf0799a522 Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Tue, 10 Jan 2023 16:25:50 -0500
Subject: [PATCH 16/19] Update website/dbt-versions.js

Co-authored-by: Leona B. Campbell <3880403+runleonarun@users.noreply.github.com>
---
 website/dbt-versions.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/dbt-versions.js b/website/dbt-versions.js
index 8f755154434..452153e9d1d 100644
--- a/website/dbt-versions.js
+++ b/website/dbt-versions.js
@@ -49,7 +49,7 @@ exports.versionedPages = [
   {
     "page": "reference/dbt-jinja-functions/print",
     "firstVersion": "1.1",
-  }
+  },
     "page": "reference/dbt-jinja-functions/local-md5",
     "firstVersion": "1.4",
 ]

From 988c8a21378556f7639f1285068c2c9694209a5d Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Tue, 10 Jan 2023 16:26:01 -0500
Subject: [PATCH 17/19] Update website/dbt-versions.js

Co-authored-by: Leona B. Campbell <3880403+runleonarun@users.noreply.github.com>
---
 website/dbt-versions.js | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/website/dbt-versions.js b/website/dbt-versions.js
index 452153e9d1d..3f682807077 100644
--- a/website/dbt-versions.js
+++ b/website/dbt-versions.js
@@ -50,6 +50,7 @@ exports.versionedPages = [
     "page": "reference/dbt-jinja-functions/print",
     "firstVersion": "1.1",
   },
-    "page": "reference/dbt-jinja-functions/local-md5",
+   { 
+   "page": "reference/dbt-jinja-functions/local-md5",
     "firstVersion": "1.4",
 ]

From 8402726c611b192ab228934ba04fa52fc0ed3a88 Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Tue, 10 Jan 2023 16:26:16 -0500
Subject: [PATCH 18/19] Update website/dbt-versions.js

Co-authored-by: Leona B. Campbell <3880403+runleonarun@users.noreply.github.com>
---
 website/dbt-versions.js | 1 +
 1 file changed, 1 insertion(+)

diff --git a/website/dbt-versions.js b/website/dbt-versions.js
index 3f682807077..eccc2a78639 100644
--- a/website/dbt-versions.js
+++ b/website/dbt-versions.js
@@ -53,4 +53,5 @@ exports.versionedPages = [
    { 
    "page": "reference/dbt-jinja-functions/local-md5",
     "firstVersion": "1.4",
+ }
 ]

From 9c8a1392f7d6d54e80d4403ee5b9c38e0f8ec00f Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Tue, 10 Jan 2023 19:34:26 -0500
Subject: [PATCH 19/19] Update single-sourcing-content.md

---
 contributing/single-sourcing-content.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contributing/single-sourcing-content.md b/contributing/single-sourcing-content.md
index cf58c799999..7a80e71728c 100644
--- a/contributing/single-sourcing-content.md
+++ b/contributing/single-sourcing-content.md
@@ -109,6 +109,7 @@ You see this block when the selected version is >= 0.21:
 
 ```markdown
 
+<VersionBlock firstVersion="0.21">
 
 ```shell
 $ dbt run --select [...] --defer --state path/to/artifacts
@@ -116,7 +117,7 @@ $ dbt test --select [...] --defer --state path/to/artifacts
 \```
 
 ```
-
+</VersionBlock>
 You see this version block when the selected version is <= 0.20
 
 ```markdown