This is a companion discussion topic for the original entry at Latest dbt: a stable foundation for improvement & innovation | dbt Developer Blog
Something I could not find and I’m curious to know is how you will make sure that packages will work as expected. Say for example the “breaking” of Elementary in the 1.8 update. When this happens, the outcome of my dbt build will change based on that update.
This would happen automatically and we could miss data quality issues.
Is there any process to capture this, to make users aware that an update actually changed their data?
2 Likes
We’re taking two approaches here:
- Testing compatibility for popular packages as part of our standard release pipelines for dbt in dbt Cloud, before changes go live for any customers.
- Gating behavior changes behind flags that are independent of upgrades to the underlying dbt runtime. The change you’re referring to is gated behind this type of a flag. In June, we changed the default value of the flag from
FalsetoTrue(“disabled” → “enabled” by default), but only after dbt Cloud customers saw deprecation warnings for months ahead of time, and received additional email notifications weeks ahead of the change if their projects were going to be affected.
1 Like