Merge pull request #2534 from dbt-labs/deprecation

Changes to docs due to 0.20/1 deprecation

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
 
@@ -116,9 +116,8 @@ $ dbt run --select [...] --defer --state path/to/artifacts
 $ dbt test --select [...] --defer --state path/to/artifacts
 \```
 
-</VersionBlock>
 ```
-
+</VersionBlock>
 You see this version block when the selected version is <= 0.20
 
 ```markdown

website/dbt-versions.js

@@ -1,4 +1,8 @@
 exports.versions = [
+  {
+    version: "1.4",
+    EOLDate: "2024-01-25",
+  },
   {
     version: "1.3",
     EOLDate: "2023-10-12",
@@ -15,14 +19,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 = [
@@ -53,5 +49,9 @@ exports.versionedPages = [
   {
     "page": "reference/dbt-jinja-functions/print",
     "firstVersion": "1.1",
-  }
+  },
+   { 
+   "page": "reference/dbt-jinja-functions/local-md5",
+    "firstVersion": "1.4",
+ }
 ]

website/docs/docs/build/incremental-models.md

@@ -79,7 +79,7 @@ A `unique_key` enables updating existing rows instead of just appending new rows
 
 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">
 
 The optional `unique_key` parameter 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.
 
@@ -282,13 +282,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.

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

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

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,23 +16,21 @@ 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 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).
 - You can select it from the version dropdown on this website, to see documentation that is accurate for use with that minor version.
 
 ### 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 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
 
@@ -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 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.
 
@@ -79,21 +73,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!

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

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"/>
 

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

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

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:
 

website/docs/faqs/Tests/testing-sources.md

@@ -26,12 +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!
-
-
-:::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`.
-:::

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