[CT-1815] [Feature] Remove required 'version' from dbt_project.yml

[seub]

Is this your first time submitting a feature request?

• I have read the expectations for open source contributors
• I have searched the existing issues, and I could not find an existing issue for this feature
• I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature

At the moment, it is required that dbt projects include a version in their dbt_project.yml, which should be a semantic version, as mentioned in the dbt doc here.

My dbt project is a git repo with its own process for creating and publishing its semantic versioning. The semantic version is not hard coded in the code base, but it is generated semi-automatically by our CI/CD. I imagine this is a common practice.

Therefore our dbt project has 2 semantic versions, the one in dbt_project.yml, which does not serve any meaningful purpose according to the dbt doc, and the git semantic version (tag).

In summary, I suggest removing the required 'version' from dbt_project.yml, because:

• it does not serve any purpose
• it is confusing as it is potentially in conflict with the git repo's own versioning.

Describe alternatives you've considered

No response

Who will this benefit?

All?

Are you interested in contributing this feature?

Sure

Anything else?

https://docs.getdbt.com/reference/project-configs/version

[jtcohen6]

@seub Thanks for opening! It's a perfectly reasonable point. I can swing back later with a fuller answer.

For now, just wanted to link some relevant thoughts I shared on this a while ago: #4453 (comment)

In that comment, I suggested that this version field could someday be enforced, and used to unlock something like dbt deps freeze. @dbeatty10 and I were just talking the other day about a different mechanism that could hypothetically unlock that — issue(s) TK.

[dbeatty10]

Love this suggestion @seub !

I distinctly remember when a colleague enlightened me that version isn't used at all. dbt_utils is a great example of a dbt package that just permanently set a dummy version number of 0.1.0 (even though its latest version is 1.0.0 as-of this writing).

Looking forward to hearing more of your thoughts @jtcohen6. (I still need to write-up our discussion we had about that different mechanism -- will drop a link in this thread once I do so.)

Some things for us to consider:

• In our current world, would it be a breaking change if we relax version from required to optional? (I suspect "no")
• In a world with dbt deps freeze, how would we want to think about the "version" of dbt packages installed via git hash or git tag or tarball URL?

[jtcohen6]

@dbeatty10 Without stealing any thunder from the forthcoming write-up — given that the only good reason I could come up with ~a year ago for continuing to require version was, "maybe we'd use this for deps" — and given our chat about other better mechanisms for doing that (if we had capacity & appetite) — I struggle to think of any other good future reason to keep requiring version today.

A colleague just asked a perfectly reasonable, related question:

Why, when I configure config-version: 2 in my dbt project file, do I still need to configure version: 2 in my yml files?

These are entirely separate versioning schemes. The reason we had to call it config-version in dbt_project.yml, back in v0.17 when we were making breaking changes to the vars structure... is because a field named version was already taken! Even though it served no purpose!

@seub So - I'd be open to relaxing this. This will just require a few targeted one-line updates, to make this Optional (None by default):

dbt-core/core/dbt/contracts/project.py

Line 187 in 065ab2e

version: Union[SemverString, float]

dbt-core/core/dbt/config/project.py

Line 528 in 065ab2e

version: Union[SemverString, float]

And we'd definitely want to update these docs: https://docs.getdbt.com/reference/project-configs/version#dbt_projectyml-versions

Would you be interested in contributing that change?

[seub]

@jtcohen6 Thank you! Yes, let me try to contribute that change.

[dbeatty10]

@seub Excited that you're going to work on that contribution! 🤩

As promised, here's the write-up for that different mechanism to unlock dbt deps freeze that @jtcohen6 and I discussed last week and was mentioned here:

• [CT-1845] [Feature] Write a file of installed versions during dbt deps #6643

[seub]

@jtcohen6 @dbeatty10 Thank you for your encouragements!

I'm stuck trying to get my dev setup to work for integration tests: make setup-db gives me errors error: connection to server at "localhost" (::1), port 5432 failed: FATAL: role "root" does not exist. I asked for help on Slack here, just mentioning it here for visibility in case either of you have an idea 🙏

[dbeatty10]

I asked for help on Slack here

We'll see if we can get to the bottom of that error -- I just sent a reply in Slack.

[seub]

Hi all, I created a PR to make the change. Thanks for your help @jtcohen6 and @dbeatty10 !

I did not add any tests. The current tests all passed. If you'd like me to add a unit or integration test, a tip would be great.

I also created an issue to update the doc.

[seub]

My PR was broken due to an email mistake, I just replaced it with a new PR: #6718