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.

timhoffm force-pushed theversion_info branch 2 times, most recently fromf60a16c to6827ff8Compare

November 1, 2020 23:36

timhoffm added the New feature label

Nov 1, 2020

timhoffm added this to thev3.4.0 milestone

Nov 1, 2020

timhoffm force-pushed theversion_info branch 4 times, most recently from15c8a0e toa916604Compare

November 2, 2020 20:37

timhoffm added the status: needs review label

Nov 8, 2020

Copy link

Contributor

dopplershift commentedNov 18, 2020

Outcome of today's call was that this should go ahead and mimic all the fields insys.version_info to handle our release candidates.

Copy link

MemberAuthor

timhoffm commentedNov 18, 2020

Waiting for#18971 before moving on.

timhoffm added status: waiting for other PR and removed status: needs review labels

Nov 18, 2020

timhoffm marked this pull request as draft

November 18, 2020 21:42

QuLogic modified the milestones:v3.4.0,v3.5.0

Jan 27, 2021

Copy link

MemberAuthor

timhoffm commentedMay 25, 2021•
edited
Loading

Waiting on#19419 (in particular#19419 (comment)).

Notes to self:

setuptools_scm usespackaging.version.parsehttps://github.com/pypa/setuptools_scm/pull/558/files but only indump_version() (and this only creates a plain tuple, not a named tuple likesys.version_info). There seems noget_version() equivalent for tuples, i.e. some programmaticget_version_info() is missing. We'll have to implement this ourselves.
I don't think we can detect thereleaselevel ('alpha', 'beta', 'candidate', or 'final'), so let's stick with 'final' if there is no dev/pre/post part and choose one of 'alpha', 'beta', 'candiate' for all others.

timhoffm force-pushed theversion_info branch 2 times, most recently from4310f23 tof564e4aCompare

July 8, 2021 21:21

timhoffm removed the status: waiting for other PR label

Jul 8, 2021

timhoffm marked this pull request as ready for review

July 8, 2021 21:23

Copy link

Member

jklymak commentedJul 8, 2021

Does this need a what's new or API note?

Copy link

MemberAuthor

timhoffm commentedJul 9, 2021

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.

timhoffm force-pushed theversion_info branch fromf564e4a to2d81709Compare

July 9, 2021 19:21

Copy link

MemberAuthor

timhoffm commentedJul 9, 2021

"What's new" added.

Add __version_info__ as a tuple-based version identifier

adbc5c5

This is a named tuple modelled after sys.version_info.

timhoffm force-pushed theversion_info branch from2d81709 toadbc5c5Compare

July 9, 2021 19:22

jklymak approved these changes

Jul 9, 2021

View reviewed changes

jklymak added the status: needs review label

Jul 20, 2021

anntzer reviewed

Jul 20, 2021

View reviewed changes

lib/matplotlib/__init__.py

		__version__ = _get_version()
		global __version__info__ # cache it.
		__version_info__ = _parse_to_version_info(__version__)
		return __version__ if name == "__version__" else __version_info__

Copy link

Contributor

anntzerJul 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I would doreturn 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.

Copy link

MemberAuthor

timhoffmJul 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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.