[Bug] dbt_project.yml does not fully support semantic versioning

[b0lle]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

One can read in the docs that semantic versioning is supported. If so, pre-versions like 1.0.0-pre.1 should be supportes (as the link in the docs says).
Currently the version number causes a Runtime Error:

Encountered an error while reading the project:
  ERROR: Runtime Error
  at path ['version']: '0.0.0-pre.1' is not valid under any of the given schemas

# dbt_project.yml

version: '1.0.0-pre.1'

Expected Behavior

Version 1.0.0-pre.1 should be an accepted version, because it follows the rules of semantic versioning

Steps To Reproduce

No response

Relevant log output

No response

Environment

- OS: macOS 11.5.2
- Python: 3.9.7
- dbt: 21.1

What database are you using dbt with?

No response

Additional Context

No response

[jtcohen6]

@b0lle Thanks for opening!

The codepath for this one is fairly straightforward, and leads us to a comment indicating that version only supports "semver lite":

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

Line 172 in 3fc715f

version: Union[SemverString, float]

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

Lines 25 to 40 in 3fc715f

	class SemverString(str, SerializableType):
	def _serialize(self) -> str:
	return self
	@classmethod
	def _deserialize(cls, value: str) -> 'SemverString':
	return SemverString(value)
	# this does not support the full semver (does not allow a trailing -fooXYZ) and
	# is not restrictive enough for full semver, (allows '1.0'). But it's like
	# 'semver lite'.
	register_pattern(
	SemverString,
	r'^(?:0|[1-9]\d*)\.(?:0|[1-9]\d*)(\.(?:0|[1-9]\d*))?$',
	)

At the same time, the docs say:

The version must be in a semantic version format, e.g. 1.0.0

Why not support real semver? Well... the version field isn't used for anything today. It serves no functional purpose. But it is required, in all projects—and I could imagine it being useful for something, someday. In particular, there's no way currently to see the currently installed versions of any packages, because there's no actual correspondence between the version in their dbt_project.yml, and the version (GitHub tag) specified in packages.yml. But imagine if they did correspond—if we did a good job of enforcing their alignment—which would unlock the ability for a dbt deps freeze to do something like:

$ dbt deps freeze
dbt-utils==0.7.1
snowplow==0.13.0

Updates available for packages: ['dbt-labs/dbt_utils', 'dbt-labs/snowplow']
Update your versions in packages.yml, then run dbt deps

Currently, that version report is only available by running dbt deps, i.e. actually re-installing packages based on the specification in packages.yml.

So, I think we have two valid options:

1. Validate this via an actual semantic version specification, such as by using dbt.semver.VersionSpecifier.from_version_string
2. Support any string in the version field, because it serves no functional purpose today. (If we do this now, though, it will be much harder to do anything useful with it in the future.)

I'm inclined to prefer the former: This should be a semantic version, rather than an anything-goes string. We already have logic (a whole module, even) dedicated to validating semantic versions.

I think the lift here would be pretty small, so I'm going to mark this a good first issue! Would you be interested in contributing the fix? :)

[alswang18]

I can handle this if no one else is @jtcohen6.

[b0lle]

I'm sorry @jtcohen6, I just didn't see your post.
Thanks for the explanation. Even though dbt does not use this flag, we have a use case where we extract the version from dbt_project to feed our CI/CD pipeline that creates a package in the package registry.

Thanks @alswang18 for creating the PR