Add __version_info__ as a tuple-based version identifier #18869
Conversation
f60a16c to
6827ff8
Compare
15c8a0e to
a916604
Compare
|
Outcome of today's call was that this should go ahead and mimic all the fields in |
|
Waiting for #18971 before moving on. |
|
Waiting on #19419 (in particular #19419 (comment)). Notes to self:
|
4310f23 to
f564e4a
Compare
|
Does this need a what's new or API note? |
|
Yes, I think "What's new" would be appropriate. I noticed that the switch to release-branch-semver does not have one either. Will do a combined one. |
|
"What's new" added. |
This is a named tuple modelled after sys.version_info.
| __version__ = _get_version() | ||
| global __version__info__ # cache it. | ||
| __version_info__ = _parse_to_version_info(__version__) | ||
| return __version__ if name == "__version__" else __version_info__ |
There was a problem hiding this comment.
I would do return globals()[name] as that seems more robust if we ever want to add more entries to the module-level __getattr__, but I'm not going to block over that.
There was a problem hiding this comment.
I'll leave this as is because explicit is better and still simple enough for two cases. We can (and should) switch to your proposal if we add more entries.
PR Summary
Closes #18312. See there for general background and discussion.
This implementation truncates the version to
(major, minor, micro). GitHub post-tag number and commit are left out: The commit ID must be left out because it is not ordered, and the tuple is specifically intended to be compared. One could leave the post-tag number. However, this is non-standard. Moreover git post-tag numbers only appear in development versions and and I doubt there's a use-case for checking only that. So let's keep it simple and to the(major, minor, micro)tuple.One can always expand later with additional parameters or switching to a namedtuple. if there is need.