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:
main
: 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/
branch should be merged into main
branch when new minor releases are created.
e.g. for releasing 0.6.0
- Create the PR to merge
dev/0.6.0
intomain
. Also update theChangelog
as part of this PR, and merge it - Create the GitHub release
- Delete the
dev/0.6.0
branch, and create a new branchdev/0.7.0
frommain
, setting it as the default branch in GitHub. - 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/
branch on top of themain
branch so that any fixes will be included in the next minor release
No dependencies need to be updated for patch releases.