Skip to content

Switch from patch-version environments to minor-version environments #36

@jaypeedevlin

Description

@jaypeedevlin

In a pre 1.0 world, new features were added in patch releases and breaking changes in minor versions. Now, new features come in minor versions and breaking changes in major versions. The assumption underpinning this proposal is that you never care about running anything but the latest patch version of a particular minor branch.

For versions >=1.0 I would like to suggest:

  • We create (eg) dbt-snowflake-1.2 rather than dbt-snowflake.1.2.x
  • We use major/minor only in version files

Additionally, I propose a command to upgrade the patch versions of both the adaptor/core in an environment (in an ideal world an environment variable might control auto-upgrading patch versions if available).

I have been running something similar by manually maintaining it locally for the past few months:

  • When a new minor version comes out, bump my ~/.dbt/version file to 1.x.0
  • When a new patch version comes out, activate the relevant venv and pip install --upgrade dbt-core dbt-snowflake

Personally I find it works really well, and saves me from "environment sprawl" just to get the latest patch version. Hoping to solicit some opinions before looking at implementation options.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions