-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extract version utils and use semver for version comparison #4844
Conversation
Codecov Report
|
6e6ed59
to
6b3af0d
Compare
eafc603
to
fb0cba8
Compare
return semver.VersionInfo(*version) | ||
except Exception: | ||
# Postgres might be in development, with format \d+[beta|rc]\d+ | ||
match = re.match(r'(\d+)([a-zA-Z]+)(\d+)', raw_version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is X.YbetaZ
possible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know. PG documentation only refers to actual releases, which are on X.Y.Z format https://www.postgresql.org/support/versioning/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to https://github.com/postgres/postgres/releases/, postgres seems to follow semver, only betas differ from semver and they seem to only apply to major versions:
For example: postgres/postgres@a240570#diff-e2d5a00791bce9a01f99bc6fd613a39dR585
We need to pass the requirements explicitly when updating a check to its development version.
…lia/pg-refactor-use-semver
def _is_10_or_above(self): | ||
return self._is_above([10, 0, 0]) | ||
@property | ||
def version(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't cache version information as it may change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The cache is cleared when wrong version is detected (see _clean_state
). Take into account we are already caching version specific information such as which queries to run
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's only cleared when an error occurs and the difference between minor releases is unlikely to cause one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, that is right and that would affect inventories project only. So I'll remove the caching as part of the PR that adds inventories. This PR is not intending to change behaviour and version was already cached (#4874 (comment))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments but looks good overall !
return semver.VersionInfo(*version) | ||
except Exception: | ||
# Postgres might be in development, with format \d+[beta|rc]\d+ | ||
match = re.match(r'(\d+)([a-zA-Z]+)(\d+)', raw_version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to https://github.com/postgres/postgres/releases/, postgres seems to follow semver, only betas differ from semver and they seem to only apply to major versions:
For example: postgres/postgres@a240570#diff-e2d5a00791bce9a01f99bc6fd613a39dR585
Use semver for version comparison, extract version_utils
There is another PR after this to submit version metadata