Removing v1.2 from docs (#5558)

## What are you changing in this pull request and why? Removing v1.2 from the docs: - removes version from dropdown - removes LastVersion='1.2' blocks - removes various references to v1.2 that no longer need the context ## Checklist  - [ ] Review the [Content style guide](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/content-style-guide.md) so my content adheres to these guidelines. - [ ] For [docs versioning](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/single-sourcing-content.md#about-versioning), review how to [version a whole page](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/single-sourcing-content.md#adding-a-new-version) and [version a block of content](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/single-sourcing-content.md#versioning-blocks-of-content). - [ ] Add a checklist item for anything that needs to happen before this PR is merged, such as "needs technical review" or "change base branch." Adding or removing pages (delete if not applicable): - [ ] Add/remove page in `website/sidebars.js` - [ ] Provide a unique filename for new pages - [ ] Add an entry for deleted pages in `website/vercel.json` - [ ] Run link testing locally with `npm run build` to update the links that point to deleted pages
dbt-labs · May 24, 2024 · 3e5a008 · 3e5a008
2 parents eb0604f + 8dd8710
commit 3e5a008
Show file tree

Hide file tree

Showing 27 changed files with 8 additions and 181 deletions.
diff --git a/website/dbt-versions.js b/website/dbt-versions.js
@@ -23,10 +23,6 @@ exports.versions = [
     version: "1.3",
     EOLDate: "2023-10-12",
   },
-  {
-    version: "1.2",
-    EOLDate: "2023-07-26",
-  },
 ]
 
 exports.versionedPages = [
@@ -166,22 +162,6 @@ exports.versionedPages = [
     "page": "reference/warehouse-setups/fal-setup",
     "firstVersion": "1.3",
   },
-  {
-    "page": "reference/dbt-jinja-functions/set",
-    "firstVersion": "1.2",
-  },
-  {
-    "page": "reference/dbt-jinja-functions/zip",
-    "firstVersion": "1.2",
-  },
-  {
-    "page": "reference/dbt-jinja-functions/cross-database-macros",
-    "firstVersion": "1.2",
-  },
-  {
-    "page": "reference/resource-configs/grants",
-    "firstVersion": "1.2",
-  },
   {
     "page": "reference/resource-configs/on_configuration_change",
     "firstVersion": "1.6",

diff --git a/website/docs/docs/build/hooks-operations.md b/website/docs/docs/build/hooks-operations.md
@@ -42,11 +42,9 @@ Hooks are a more-advanced capability that enable you to run custom SQL, and leve
 
 <Snippet path="hooks-to-grants" />
 
-<VersionBlock firstVersion="1.2">
-
 If (and only if) you can't leverage the [`grants` resource-config](/reference/resource-configs/grants), you can use `post-hook` to perform more advanced workflows:
 
-* Need to apply `grants` in a more complex way, which the dbt Core v1.2 `grants` config does not (yet) support.
+* Need to apply `grants` in a more complex way, which the dbt Core `grants` config doesn't (yet) support.
 * Need to perform post-processing that dbt does not support out-of-the-box. For example, `analyze table`, `alter table set property`, `alter table ... add row access policy`, etc.
 
 ### Examples using hooks
@@ -70,8 +68,6 @@ You can use hooks to provide database-specific functionality not available out-o
 </File>
 
 
-</VersionBlock>
-
 ### Calling a macro in a hook
 
 You can also use a [macro](/docs/build/jinja-macros#macros) to bundle up hook logic. Check out some of the examples in the reference sections for [on-run-start and on-run-end hooks](/reference/project-configs/on-run-start-on-run-end) and [pre- and post-hooks](/reference/resource-configs/pre-hook-post-hook).

diff --git a/website/docs/docs/build/incremental-strategy.md b/website/docs/docs/build/incremental-strategy.md
@@ -269,8 +269,6 @@ select * from {{ ref("some_model") }}
 
 ### Custom strategies
 
-<VersionBlock firstVersion="1.2">
-
 Starting from dbt version 1.2 and onwards, users have an easier alternative to [creating an entirely new materialization](/guides/create-new-materializations). They define and use their own "custom" incremental strategies by:
 
 1. Defining a macro named `get_incremental_STRATEGY_sql`. Note that `STRATEGY` is a placeholder and you should replace it with the name of your custom incremental strategy.
@@ -334,7 +332,6 @@ To use the `merge_null_safe` custom incremental strategy from the `example` pack
 ```
 
 </File>
-</VersionBlock>
 
 <Snippet path="discourse-help-feed-header" />
 <DiscourseHelpFeed tags="incremental"/>
diff --git a/website/docs/docs/build/python-models.md b/website/docs/docs/build/python-models.md
@@ -16,14 +16,6 @@ We encourage you to:
 
 dbt Python (`dbt-py`) models can help you solve use cases that can't be solved with SQL. You can perform analyses using tools available in the open-source Python ecosystem, including state-of-the-art packages for data science and statistics. Before, you would have needed separate infrastructure and orchestration to run Python transformations in production. Python transformations defined in dbt are models in your project with all the same capabilities around testing, documentation, and lineage.
 
-<VersionBlock lastVersion="1.2">
-
-Python models are supported in dbt Core 1.3 and higher.  Learn more about [upgrading your version in dbt Cloud](https://docs.getdbt.com/docs/dbt-cloud/cloud-configuring-dbt-cloud/cloud-upgrading-dbt-versions) and [upgrading dbt Core versions](https://docs.getdbt.com/docs/core-versions#upgrading-to-new-patch-versions).
-
-To read more about Python models, change the [docs version to 1.3](/docs/build/python-models?version=1.3) (or higher) in the menu bar.
-
-</VersionBlock>
-
 <VersionBlock firstVersion="1.3">
 
 <File name='models/my_python_model.py'>

diff --git a/website/docs/docs/core/connect-data-platform/connection-profiles.md b/website/docs/docs/core/connect-data-platform/connection-profiles.md
@@ -19,11 +19,6 @@ profile: 'jaffle_shop'
 
 dbt then checks your [`profiles.yml` file](/docs/core/connect-data-platform/profiles.yml) for a profile with the same name. A profile contains all the details required to connect to your data warehouse.
 
-<VersionBlock lastVersion="1.2">
-
-By default, dbt expects the `profiles.yml` file to be located in the `~/.dbt/` directory.
-
-</VersionBlock>
 <VersionBlock firstVersion="1.3">
 
 dbt will search the current working directory for the `profiles.yml` file and will default to the `~/.dbt/` directory if not found.
@@ -140,13 +135,6 @@ For more information, check out [using threads](/docs/running-a-dbt-project/usin
 
 The parent directory for `profiles.yml` is determined using the following precedence:
 
-<VersionBlock lastVersion="1.2">
-
-1. `--profiles-dir` option
-1. `DBT_PROFILES_DIR` environment variable
-1. `~/.dbt/` directory
-
-</VersionBlock>
 <VersionBlock firstVersion="1.3">
 
 1. `--profiles-dir` option

diff --git a/website/docs/docs/core/connect-data-platform/oracle-setup.md b/website/docs/docs/core/connect-data-platform/oracle-setup.md
@@ -406,7 +406,6 @@ export DBT_ORACLE_HOST=adb.example.oraclecloud.com
 export DBT_ORACLE_SERVICE=example_high.adb.oraclecloud.com
 ```
 
-<VersionBlock firstVersion="1.2">
 <File name='~/.dbt/profiles.yml'>
 
 ```yaml
@@ -428,7 +427,6 @@ dbt_test:
          threads: 4
 ```
 </File>
-</VersionBlock>
 
 </TabItem>
 

diff --git a/website/docs/docs/core/connect-data-platform/postgres-setup.md b/website/docs/docs/core/connect-data-platform/postgres-setup.md
@@ -88,10 +88,8 @@ If the database closes its connection while dbt is waiting for data, you may see
 
 [dbt's default setting](https://github.com/dbt-labs/dbt-core/blob/main/plugins/postgres/dbt/adapters/postgres/connections.py#L28) is 0 (the server's default value), but can be configured lower (perhaps 120 or 60 seconds), at the cost of a chattier network connection.
 
-<VersionBlock firstVersion="1.2">
 
 #### retries
 
 If `dbt-postgres` encounters an operational error or timeout when opening a new connection, it will retry up to the number of times configured by `retries`. The default value is 1 retry. If set to 2+ retries, dbt will wait 1 second before retrying. If set to 0, dbt will not retry at all.
 
-</VersionBlock>
diff --git a/website/docs/docs/core/connect-data-platform/redshift-setup.md b/website/docs/docs/core/connect-data-platform/redshift-setup.md
@@ -243,11 +243,8 @@ To run certain macros with autocommit, load the profile with autocommit using th
 Where possible, dbt enables the use of `sort` and `dist` keys. See the section on [Redshift specific configurations](/reference/resource-configs/redshift-configs).
 
 
-
-<VersionBlock firstVersion="1.2">
-
 #### retries
 
 If `dbt-redshift` encounters an operational error or timeout when opening a new connection, it will retry up to the number of times configured by `retries`. If set to 2+ retries, dbt will wait 1 second before retrying. The default value is 1 retry. If set to 0, dbt will not retry at all.
 
-</VersionBlock>
+
diff --git a/website/docs/reference/commands/init.md b/website/docs/reference/commands/init.md
@@ -40,8 +40,6 @@ If you've just cloned or downloaded an existing dbt project, `dbt init` can stil
 
 - **Existing project:** If you're the maintainer of an existing project, and you want to help new users get connected to your database quickly and easily, you can include your own custom `profile_template.yml` in the root of your project, alongside `dbt_project.yml`. For common connection attributes, set the values in `fixed`; leave user-specific attributes in `prompts`, but with custom hints and defaults as you'd like.
 
-<VersionBlock firstVersion="1.2">
-
 <File name='profile_template.yml'>
 
 ```yml
@@ -70,7 +68,6 @@ prompts:
 
 </File>
 
-</VersionBlock>
 
 ```
 $ dbt init

diff --git a/website/docs/reference/dbt-jinja-functions/cross-database-macros.md b/website/docs/reference/dbt-jinja-functions/cross-database-macros.md
@@ -18,55 +18,6 @@ Please make sure to take a look at the [SQL expressions section](#sql-expression
 
 ## All functions (alphabetical)
 
-<VersionBlock firstVersion="1.2" lastVersion="1.2">
-
-- [Cross-database macros](#cross-database-macros)
-  - [All functions (alphabetical)](#all-functions-alphabetical)
-  - [Data type functions](#data-type-functions)
-    - [type\_bigint](#type_bigint)
-    - [type\_boolean](#type_boolean)
-    - [type\_float](#type_float)
-    - [type\_int](#type_int)
-    - [type\_numeric](#type_numeric)
-    - [type\_string](#type_string)
-    - [type\_timestamp](#type_timestamp)
-    - [current\_timestamp](#current_timestamp)
-  - [Set functions](#set-functions)
-    - [except](#except)
-    - [intersect](#intersect)
-  - [Array functions](#array-functions)
-    - [array\_append](#array_append)
-    - [array\_concat](#array_concat)
-    - [array\_construct](#array_construct)
-  - [String functions](#string-functions)
-    - [concat](#concat)
-    - [hash](#hash)
-    - [length](#length)
-    - [position](#position)
-    - [replace](#replace)
-    - [right](#right)
-    - [split\_part](#split_part)
-  - [String literal functions](#string-literal-functions)
-    - [escape\_single\_quotes](#escape_single_quotes)
-    - [string\_literal](#string_literal)
-  - [Aggregate and window functions](#aggregate-and-window-functions)
-    - [any\_value](#any_value)
-    - [bool\_or](#bool_or)
-    - [listagg](#listagg)
-  - [Cast functions](#cast-functions)
-    - [cast](#cast)
-    - [cast\_bool\_to\_text](#cast_bool_to_text)
-    - [safe\_cast](#safe_cast)
-  - [Date and time functions](#date-and-time-functions)
-    - [date](#date)
-    - [dateadd](#dateadd)
-    - [datediff](#datediff)
-    - [date\_trunc](#date_trunc)
-    - [last\_day](#last_day)
-  - [Date and time parts](#date-and-time-parts)
-  - [SQL expressions](#sql-expressions)
-
-</VersionBlock>
 <VersionBlock firstVersion="1.3">
 
 - [Cross-database macros](#cross-database-macros)
@@ -117,17 +68,6 @@ Please make sure to take a look at the [SQL expressions section](#sql-expression
 
 </VersionBlock>
 
-<VersionBlock firstVersion="1.2" lastVersion="1.2">
-
-[**Data type functions**](#data-type-functions)
-- [type_bigint](#type_bigint)
-- [type_float](#type_float)
-- [type_int](#type_int)
-- [type_numeric](#type_numeric)
-- [type_string](#type_string)
-- [type_timestamp](#type_timestamp)
-
-</VersionBlock>
 <VersionBlock firstVersion="1.3">
 
 [**Data type functions**](#data-type-functions)

diff --git a/website/docs/reference/dbt-jinja-functions/modules.md b/website/docs/reference/dbt-jinja-functions/modules.md
@@ -51,8 +51,6 @@ This variable is a pointer to the Python [re](https://docs.python.org/3/library/
 {% endif %}
 ```
 
-<VersionBlock firstVersion="1.2">
-
 ## itertools
 This variable is a pointer to the Python [itertools](https://docs.python.org/3/library/itertools.html) module, which includes useful functions for working with iterators (loops, lists, and the like).
 
@@ -92,4 +90,3 @@ The supported functions are:
   (2, 'z')
 ```
 
-</VersionBlock>
diff --git a/website/docs/reference/global-configs/json-artifacts.md b/website/docs/reference/global-configs/json-artifacts.md
@@ -16,12 +16,10 @@ dbt run --no-write-json
 
 </File>
 
-<VersionBlock firstVersion="1.2">
 
 ### Target path
 
 By default, dbt will write JSON artifacts and compiled SQL files to a directory named `target/`. This directory is located relative to `dbt_project.yml` of the active project.
 
 Just like other global configs, it is possible to override these values for your environment or invocation by using the CLI option (`--target-path`) or environment variables (`DBT_TARGET_PATH`).
 
-</VersionBlock>
diff --git a/website/docs/reference/global-configs/logs.md b/website/docs/reference/global-configs/logs.md
@@ -79,15 +79,13 @@ dbt --debug run
 
 </File>  
 
-<VersionBlock firstVersion="1.2">
 
 ### Log and target paths
 
 By default, dbt will write logs to a directory named `logs/`, and all other artifacts to a directory named `target/`. Both of those directories are located relative to `dbt_project.yml` of the active project.
 
 Just like other global configs, it is possible to override these values for your environment or invocation by using CLI options (`--target-path`, `--log-path`) or environment variables (`DBT_TARGET_PATH`, `DBT_LOG_PATH`).
 
-</VersionBlock>
 
 ### Suppress non-error logs in output
 

diff --git a/website/docs/reference/global-configs/project-flags.md b/website/docs/reference/global-configs/project-flags.md
@@ -40,7 +40,7 @@ config:
 
 </VersionBlock>
 
-<VersionBlock firstVersion="1.2" lastVersion="1.7">
+<VersionBlock lastVersion="1.7">
 
 The exception: Some global configurations are actually set in `dbt_project.yml`, instead of `profiles.yml`, because they control where dbt places logs and artifacts. Those file paths are always relative to the location of `dbt_project.yml`. For more details, refer to [Log and target paths](/reference/global-configs/logs#log-and-target-paths).
 

diff --git a/website/docs/reference/node-selection/methods.md b/website/docs/reference/node-selection/methods.md
@@ -75,8 +75,6 @@ selectors unambiguous.
   ```
 
 
-<VersionBlock firstVersion="1.2">
-
 ### The "file" method
 The `file` method can be used to select a model by its filename, including the file extension (`.sql`).
 
@@ -87,8 +85,6 @@ dbt run --select "some_model.sql"
 dbt run --select "some_model"
 ```
 
-</VersionBlock>
-
 ### The "fqn" method
 
 The `fqn` method is used to select nodes based off their "fully qualified names" (FQN) within the dbt graph. The default output of [`dbt list`](/reference/commands/list) is a listing of FQN. The default FQN format is composed of the project name, subdirectories within the path, and the file name (without extension) separated by periods.

diff --git a/website/docs/reference/node-selection/yaml-selectors.md b/website/docs/reference/node-selection/yaml-selectors.md
@@ -367,8 +367,6 @@ selectors:
     definition: ...
 ```
 
-<VersionBlock firstVersion="1.2">
-
 ### Selector inheritance
 
 Selectors can reuse and extend definitions from other selectors, via the `selector` method.
@@ -396,6 +394,3 @@ selectors:
 **Note:** While selector inheritance allows the logic from another selector to be _reused_, it doesn't allow the logic from that selector to be _modified_ by means of `parents`, `children`, `indirect_selection`, and so on. 
 
 The `selector` method returns the complete set of nodes returned by the named selector.
-
-
-</VersionBlock>
diff --git a/website/docs/reference/resource-configs/enabled.md b/website/docs/reference/resource-configs/enabled.md
@@ -176,12 +176,6 @@ sources:
 
 <TabItem value="metrics">
 
-<VersionBlock lastVersion="1.2">
-
-Support for disabling metrics was added in dbt Core v1.3
-
-</VersionBlock>
-
 <VersionBlock firstVersion="1.3">
 
 <File name='dbt_project.yml'>
@@ -213,12 +207,6 @@ metrics:
 
 <TabItem value="exposures">
 
-<VersionBlock lastVersion="1.2">
-
-Support for disabling exposures was added in dbt Core v1.3
-
-</VersionBlock>
-
 <VersionBlock firstVersion="1.3">
 
 <File name='dbt_project.yml'>

diff --git a/website/docs/reference/resource-configs/grants.md b/website/docs/reference/resource-configs/grants.md
@@ -11,7 +11,7 @@ The grant resource configs enable you to apply permissions at build time to a sp
 
 dbt aims to use the most efficient approach when updating grants, which varies based on the adapter you're using, and whether dbt is replacing or updating an object that already exists. You can always check the debug logs for the full set of grant and revoke statements that dbt runs.
 
-dbt encourages you to use grants as resource configs whenever possible in Core v1.2 and higher. In versions prior to Core v1.2, you were limited to using hooks for grants. Occasionally, you still might need to write grants statements manually and run them using hooks. For example, hooks may be appropriate if you want to:
+dbt encourages you to use grants as resource configs whenever possible. In versions prior to Core v1.2, you were limited to using hooks for grants. Occasionally, you still might need to write grants statements manually and run them using hooks. For example, hooks may be appropriate if you want to:
 
 * Apply grants in a more complex or custom manner, beyond what the built-in grants capability can provide.
 * Apply grants on other database objects besides views and tables.

diff --git a/website/docs/reference/resource-configs/persist_docs.md b/website/docs/reference/resource-configs/persist_docs.md
@@ -137,12 +137,8 @@ Some known issues and limitations:
 
 <div warehouse="Snowflake">
 
-<VersionBlock firstVersion="1.2">
-
 - No known issues
 
-</VersionBlock>
-
 </div>
 
 </WHCode>

diff --git a/website/docs/reference/resource-configs/plus-prefix.md b/website/docs/reference/resource-configs/plus-prefix.md
@@ -63,8 +63,5 @@ models:
 
 When adding configs in `dbt_project.yml`, it doesn't hurt to use the `+` prefix, so we recommend you use it always.
 
-<VersionBlock firstVersion="1.2">
-
 **Note:** This use of the `+` prefix, in `dbt_project.yml`, is distinct from the use of `+` to control config merge behavior (clobber vs. add) in other config settings (specific resource `.yml` and `.sql` files). Currently, the only config which supports `+` for controlling config merge behavior is [`grants`](/reference/resource-configs/grants#grant-config-inheritance).
 
-</VersionBlock>