Merge branch 'current' into ly-docs-versionless-cloud

website/docs/docs/cloud/manage-access/audit-log.md

@@ -173,10 +173,3 @@ You can use the audit log to export all historical audit results for security, c
 - **For events beyond 90 days** — Select **Export All**. The Account Admin will receive an email link to download a CSV file of all the events that occurred in your organization.
 
 <Lightbox src="/img/docs/dbt-cloud/dbt-cloud-enterprise/audit-log-section.jpg" width="95%" title="View audit log export options"/>
-
-### Azure Single-tenant
-
-For users deployed in [Azure single tenant](/docs/cloud/about-cloud/tenancy), while the **Export All** button isn't available, you can conveniently use specific APIs to access all events:
-
-- [Get recent audit log events CSV](/dbt-cloud/api-v3#/operations/Get%20Recent%20Audit%20Log%20Events%20CSV) &mdash; This API returns all events in a single CSV without pagination.
-- [List recent audit log events](/dbt-cloud/api-v3#/operations/List%20Recent%20Audit%20Log%20Events) &mdash; This API returns a limited number of events at a time, which means you will need to paginate the results.

website/docs/docs/core/installation-overview.md

@@ -32,7 +32,7 @@ You can install dbt Core on the command line by using one of these methods:
 
 ## Upgrading dbt Core
 
-dbt provides a number of resources for understanding [general best practices](/blog/upgrade-dbt-without-fear) while upgrading your dbt project as well as detailed [migration guides](/docs/dbt-versions/core-upgrade/upgrading-to-v1.4) highlighting the changes required for each minor and major release, and [core versions](/docs/dbt-versions/core)
+dbt provides a number of resources for understanding [general best practices](/blog/upgrade-dbt-without-fear) while upgrading your dbt project as well as detailed [migration guides](/docs/dbt-versions/core-upgrade) highlighting the changes required for each [minor and major release](/docs/dbt-versions/core).
 
 - [Upgrade `pip`](/docs/core/pip-install#change-dbt-core-versions)
 

website/docs/guides/mesh-qs.md

@@ -460,10 +460,10 @@ models:
 ### Set up model versions
 In this section, you will set up model versions by the Data Analytics team as they upgrade the `fct_orders` model while offering backward compatibility and a migration notice to the downstream Finance team.
 
-1. Rename the existing model file from` models/core/fct_orders.sql` to `models/core/fct_orders_v1.sql`.
+1. Rename the existing model file from `models/core/fct_orders.sql` to `models/core/fct_orders_v1.sql`.
 2. Create a new file `models/core/fct_orders_v2.sql` and adjust the schema:
-   - Comment out `orders.status`  
-   - Add a new field, `is_return` to indicate if an order was returned.
+   - Comment out `o.status` in the `final` CTE.
+   - Add a new field, `case when o.status = 'returned' then true else false end as is_return` to indicate if an order was returned.
 3. Then, add the following to your `models/core/core.yml` file:
    - The `is_return` column
    - The two model `versions`

website/docs/reference/resource-configs/contract.md

@@ -14,6 +14,8 @@ When the `contract` configuration is enforced, dbt will ensure that your model's
 
 This is to ensure that the people querying your model downstream—both inside and outside dbt—have a predictable and consistent set of columns to use in their analyses. Even a subtle change in data type, such as from `boolean` (`true`/`false`) to `integer` (`0`/`1`), could cause queries to fail in surprising ways.
 
+## Data type aliasing
+
 <VersionBlock lastVersion="1.6">
 
 The `data_type` defined in your YAML file must match a data type your data platform recognizes. dbt does not do any type aliasing itself. If your data platform recognizes both `int` and `integer` as corresponding to the same type, then they will return a match.
@@ -42,11 +44,13 @@ models:
 </File>
 </VersionBlock>
 
+## Size, precision, and scale
+
 When dbt compares data types, it will not compare granular details such as size, precision, or scale. We don't think you should sweat the difference between `varchar(256)` and `varchar(257)`, because it doesn't really affect the experience of downstream queriers. You can accomplish a more-precise assertion by [writing or using a custom test](/best-practices/writing-custom-generic-tests).
 
 Note that you need to specify a varchar size or numeric scale, otherwise dbt relies on default values. For example, if a `numeric` type defaults to a precision of 38 and a scale of 0, then the numeric column stores 0 digits to the right of the decimal (it only stores whole numbers), which might cause it to fail contract enforcement. To avoid this implicit coercion, specify your `data_type` with a nonzero scale, like `numeric(38, 6)`. dbt Core 1.7 and higher provides a warning if you don't specify precision and scale when providing a numeric data type.
 
-## Example
+### Example
 
 <File name='models/dim_customers.yml'>