There's a few scenarios that might prompt a release:
Scenario | Release type |
---|---|
New functionality¹ | minor |
Breaking changes to existing macros | minor |
Fixes to existing macros | patch |
dbt minor release with no breaking changes | patch |
dbt minor release with breaking changes | minor |
¹New macros were previously considered patch releases — we have brought them up to minor releases to make versioning for dependencies clearer.
At any point, there should be two long-lived branches:
master
(default): This reflects the most recent release of dbt-utilsdev/0.x.0
: This reflects the next minor release, wherex
will be replaced with the minor version number
The dev/0.x.0
branch should be merged into master
branch when new releases are created.
e.g. for releasing 0.x.0
- Create the PR to merge
dev/0.x.0
intomaster
. Also update theChangelog
as part of this PR, and merge it. - Create the GitHub release from the
master
branch. - Delete the
dev/0.x.0
branch, and create a new branchdev/0.x+1.0
frommaster
, adding branch protection to it. - Create a new issue from the "dbt-utils Minor Release Follow-Up" template to also update any dependencies.
- Create the release.
- Then rebase the current
dev/0.x.0
branch on top of themaster
branch so that any fixes will be included in the next minor release.
No dependent packages need to be updated for patch releases (e.g. codegen, audit-helper)